[Boards: 3 / a / aco / adv / an / asp / b / biz / c / cgl / ck / cm / co / d / diy / e / fa / fit / g / gd / gif / h / hc / his / hm / hr / i / ic / int / jp / k / lgbt / lit / m / mlp / mu / n / news / o / out / p / po / pol / qa / r / r9k / s / s4s / sci / soc / sp / t / tg / toy / trash / trv / tv / u / v / vg / vp / vr / w / wg / wsg / wsr / x / y ] [Home]
4chanarchives logo
Schillsaver General - 9
Images are sometimes not shown due to bandwidth/network limitations. Refreshing the page usually helps.

You are currently reading a thread in /g/ - Technology

Thread replies: 101
Thread images: 13
File: Splash - Copy.png (56 KB, 512x512) Image search: [Google]
Splash - Copy.png
56 KB, 512x512
Continued from previous thread.

>>51247396

-------------------------------------

Version 5 is now out. See more information, or download Schillsaver, from the following page.

http://valkryst.com/schillsaver/index.html

I recommend reading through most of the instructions either on the webpage or in the readme
file as you're setting up the program for the first time.

-------------------------------------

The GitHub page is at the following link.

https://github.com/Valkryst/Schillsaver

-------------------------------------

Test #1:

This test took a ~64Mb file, archived it with 7z down to ~60Mb, and encoded it in 20 minutes
into a~126Mb mkv file.

It was uploaded to YTusing the "yt:quality=high" tag and it processed perfectly fine.
When downloading with the ClipConverter site it was retrieved as a ~366Mb mp4 file.

Decoding the ~126Mb mkv file took ~2 minutes. Same for the ~366Mb file.


Test #2:

This test took a ~3GB file, archived it with 7z to 3GB, and encoded it in 23h25m into a ~8.7GB
video file on a dual core G3220. See >>51133373

-------------------------------------

Some of the more useful info from the original (4?) threads can be found here. It's all out of context, but eh.

http://pastebin.com/BLdea0nY

-------------------------------------

FAQ can be found at the following link.

http://pastebin.com/qbeY51Jm

-------------------------------------
>>
first
>>
>>51266054
This is really interesting but why should I use this?
>>
>>51267041
wew lad. you sure showed him
>>
>>51267230
It's essentially free file storage.

The main, simple, use case where I can see this being used would be to share smaller files among friends without needing to find a working, non-speed-capped, virus free, etc... storage site.

Although, when Schillserver is ready, this can be use for large-scale file storage.
>>
>>51267320
I see. I just use spiderOak so I guess its not for me
>>
>>51267350
>spiderOak

Yeah, I wouldn't recommend actually using this as your only backup, but if you don't want to pay to store your files, and you have a lot to store and a lot of computing power to encode with, then this might be an acceptable alternative.
>>
>>51267398
But why?
>>
It could also be used as an alternative to torrenting as everyone would always get their maximum download speed when downloading the video from YouTube thanks to their CDN, so if the video is downloaded through a third party, then it might be about as safe as torrenting (which isn't even safe...).

But the filesize being downloaded is at-least 3x the filesize of the original file.

>>51267436
Just because we can. We're really only working on Schillsaver/server for something to do, it's fun.
>>
What does the application look like? I don't have Java.
>>
File: 1447011431875.png (54 KB, 1649x661) Image search: [Google]
1447011431875.png
54 KB, 1649x661
>>51267477
Two screens from a few days ago.
>>
>>51266054
>java

into >>>/trash/
>>
>>51267450
Oh my bad I thought you meant dont use SpiderOak. I love the idea. Ill dl and try it out
>>
File: 1096.gif (1 MB, 250x230) Image search: [Google]
1096.gif
1 MB, 250x230
>>51267505
>>
>>51267538
If you've got a better design, throw it at me.

The stylesheet is here.

https://github.com/Valkryst/Schillsaver/blob/master/src/main/resources/global.css
>>
Fun experiment, but trying to pass it off as an advantageous way of getting "free file storage" seems a bit ridiculous to me.

I mean if you're gonna do this via a YT account, might as well use botnets the way they're meant supposed to and use google drive's free 15GB + Dropbox's free 16GB, all of which are a lot easier to share than this thing. By the time you're done uploading your 30x3 = 90GB of garbage video explicitly violating YT's TOS, your account will be suspended.

And as if that's not enough, you can use shit like Rackspace Cloud Files which normally deal in the 100s of GBs and write off your monthly bills when they're too small to collect (source: my site is on that and I haven't paid a penny)

But for a fun esoteric way of sharing zip files full of dank memes, sure, knock yussef out
>>
You need to implement this in JS.
>>
File: shot0328.jpg (95 KB, 441x441) Image search: [Google]
shot0328.jpg
95 KB, 441x441
>>51267990
>encoding video
>IN JAVASCRIPT
s
m
h

f
a
m
>>
>>51267927
Yeah, it's definitely not that useful. I just come up with ways it can be used when explaining it.

I get where you're coming from.

Oh, the upload would actually be only around 30GB assuming you've encoded 15GB of files. It'd be 90GB of less when downloading it back.

This is TOTALLY useless if you don't have a really decent connection with no bandwidth caps.

>>51267990
That would be nearly impossible IMHO, unless you want to rewrite all of the necessary parts of FFMPEG into JavaScript.

Plus, the en/decoding speed using JavaScript with a JS implementation of FFMPEG would be totally pointless. It's slow enough as-is even though FFMPEG is written in (C, C++?).

Unless you can call local programs from a JS browser script, which I don't know if you can or not. At that point it'd do the same job that Schillsaver does now, which is essentially a GUI wrapper around FFMPEG that allows for easier management of Jobs, settings, etc...
>>
>>51268107
Obviously, you use JS to queue up a request on a web backend somewhere.

Fucking idiot
>>
>>51268189
Already planned with Schillserver. It's a way to do distributed encoding from a master (with a web GUI) to slaves.
>>
>>51268189
>impement this in JS
>this
"this" is a project which employs ffmpeg to encode files to video.
To implement this concept in JavaScript would mean to port the ffmpeg suite to it.

I've been working on a distribution server for days now, family.
>>
Currently working on a basic StatisticsHandler that will, as the user runs more and more en/decode Jobs, get a better estimation of the time it'll take for a Job to run based on the total file size of all files set to the Job.

Might be done tonight, but we'll see.
>>
Annnd the new version of Schillsaver is out. As you run more en/decoding Jobs, the program will accumulate more and more data (saved locally only) on the time it takes for each file from each Job to be processed.

The program will slowly refine it's estimated processing times until it reaches a point where it can, hopefully, fairly accurately estimate the amount of time it will take for a Job to run.

valkryst.com/schillsaver/index.html
>>
>Schillsaver can be used for the same purpose, but with video files as the magnetic tapes and video-hosting services as the off-site location.
Has anyone actually tried this? Maybe on VHS?

Interesting technology, although I don't have any use for it
>>
>>51269627
Interesting though there, it's not actually what I meant when writing that, but I think storing the file on a VHS tape could work if you used a RAR archive with recovery (partition?) to ensure there's no data loss from any scratches or that on the VHS tape.

The only real downside to that would be that the video files can get quite long, so if you can't store at-least 1080p at 60fps or better on the tape, then you'd be using multiple VHS tapes for a single large file. I think it was something like 20 minutes for a 126MB file, but I can't recall.
>>
>>51269627
Certainly possible to tweak this for VHS, might need bigger blocks though or a larger recovery record. You'd get absolutely garbage storage capacity though, but I suppose it could work as a way to hide data "in plain sight" steg style. You could certainly store a lot of plain text or even images on VHS tapes and put them inside your titanic and Leslie Nielsen VHS covers and none would be the wiser unless they actually tried to watch them.
>>
>>51271160
Well, you can buy VHS tapes for a dollar down at the dollar store, so it might still.... nah... there's no way it'd be cost effective lol...

Still, it's a very interesting way to hide small amounts of sensitive data in plain sight. Honestly, how many people would think of digitizing your copy of "Extreme Lesbian Watersports Vol.6 - The Wild Wetest" for your secret passwords?
>>
>>51269627
>>51269827
>>51271160
>>51271416
The methods we've been using probably wouldn't stand up to VHS distortions, scanlines, color anomalies. We'd need to build in very, very heavy ECC (50%+ redundancy) to even have a semblance of success in storing to it
>>
>>51272220
Ah, drat. Totally forgot about all of that.

Haven't even seen a VHS tape being played in years though...
>>
What's stopping Google from patching this?

also further proof that piracy literally cannot be stopped.
>>
File: 1445894607716.jpg (51 KB, 604x340) Image search: [Google]
1445894607716.jpg
51 KB, 604x340
Holy shit, I remember the first thread when someone suggested saving data as QR and uploading to youtube.

You're a cool guy, anon.
>>
>>51272965
Nothing at all, but I have my doubts that they can easily make an algorithm to scan every single video uploaded to YT for files that actually are stored data and not just actual crap files.

They also let people upload random shit that's more of a waste of their server-space than this would be, so I don't see why they wouldn't just allow it.

I've actually thought of using this for piracy. It's entirely possible right now. All you'd need is someone to spend the time to encode the files and upload it.

Then, anyone with enough bandwidth, can just download the video, decode, and bam. You've got the latest version of Photoshop downloading at a very high speed thanks to YT's CDN.
>>
File: lib.png (4 MB, 1947x1091) Image search: [Google]
lib.png
4 MB, 1947x1091
>>51272401
4chan has already patched numerous file embed techniques in their images and webms.

but not this one :^)
>>
File: kZdopKhFaGt.png (4 MB, 1339x756) Image search: [Google]
kZdopKhFaGt.png
4 MB, 1339x756
>>51274646
or this one
>>
>>51267554
How did you use CSS for Java Components?
>>
>>51268177
Of course it's possible, you just have to use Node.js

>people enter the website
>they connect to the socket.io thingy
>when they upload the file and click convert node spawns ffmpeg
>if the socket disconnects you kill the process
>>
>>51274719
I don't know about files, but there's an in-browser script that lets you hide text inside of images, complete with private messages between contacts and such.

Too bad no one's using it.
>>
>>51274646
>>51274719

What is the decode instruction?
>>
>>51268177
>unless you want to rewrite all of the necessary parts of FFMPEG into JavaScript.

https://bgrins.github.io/videoconverter.js/
>>
What if we set FPS at 120 or 240 or 600?
>>
>>51276360
That's Desu-Desu talk
https://github.com/desudesutalk/desudesutalk

Russian dollfags are out of this world.
>>
kek cool to see you're using my logo senpai.
I don't think Schillsaver is a particularly good name for it though.
>>
>>51275255
JavaFX allows you to use CSS for styling.
>>
>>51276303
It wouldn't work out very well for anything large though... unless you're using Schillserver when it's done. FFMPEG is a resource hog, so you'd have to limit the filesize to a megabyte or two to ensure the server can get Jobs done without a huge backlog of requests.

>>51278506
You'll pack the same amount of data into a shorter video. No filesize changes IIRC.
>>
>>51266054
GUIES GUIES GUIES

YOU'RE USING THIS ALL WRONG

i kidding though, but i mean....

How would someone say use this tech, to encode say AES encrypted data to an image, rather than your method of using it for videos?

I remember something about ffmpeg in the beginning? not sure how this works.

I've only kinda sorta been following this but not really, the concept is fucking brilliant guys...

but what if....
ready?

What if, we create a decentralized encrypted messaging app, that only requires an internet connection to download the app.

>encrypted text
>encode as image
>SEND SMS
>decrypt on other phone

anyone knows what happens to an image once its sent as SMS?
>>
>>51267320
>It's essentially free file storage.

>microsoft no longer allowing the purchase of unlimited onedrive accounts
>due to people "abusing" it and uploading terabytes of movie collections

whats to say google wont do the same.
>>
>>51280983
Well, you'd encrypt the data with AES, then run it through Schillsaver to encode it as video, then send it, then decode it, then decrypt it, then view it.

It'd work for a messaging app, but I don't believe it'd be all that useful since anyone would be able to decode the video file and, if they have the key, decrypt the decoded file.

>>51280999
They might, but the processing power to encrypt terabytes of data would be massive. Even with Schillserver (when it's done), it'd take a long time.
>>
>>51280983
Also, if you encrypted it as a single image, then the amount of data you could store is limited to the maximum filesize of an image that can be sent over MMS (texting).

In that case, you could probably send a lossless image, so you wouldn't need any sort of error recovery....

It'd still be a bit useless though. Anyone could decode the data.
>>
File: PoorCloud.png (12 KB, 552x319) Image search: [Google]
PoorCloud.png
12 KB, 552x319
>>51279059
Introducing "PoorCloud"

It's a cloud with his pockets turned inside-out if my artistic skills are not up to par.
>>
>>51282075
I think we've got our mascot.
>>
>>51282075
poor cloud :(

has my vote
>>
This is so immensely retarded I can't find the words to describe how moronic it is.

300% overhead? What a hot new file sharing idea! Awesome! Not to mention the wonderful encoding and decoding times.

This is Fisher Price baby's first binary encoding scheme for /g/ kiddies who were born after web 2.0.

Have fun playing with your toys, children.
>>
>>51282275
<3 I'll make sure to have a lot of fun.
>>
>>51282293
Be sure to print off some frames from your super cool secret encoded videos so your mum can hang it on the fridge.
>>
>>51282358
...that is the single greatest idea I have ever heard. Doing it right now. Gimme a few minutes.
>>
File: 7691403944.jpg (3 MB, 3264x1836) Image search: [Google]
7691403944.jpg
3 MB, 3264x1836
I think mum is going to love it.
>>
>>51282639
pretty great
I like the PoorCloud logo

why are you not using colors instead of black+white?
>>
>>51282848
Thanks, it took a lot of effort to color within the lines.

Well, I honestly don't know enough about how all of this works to implement that properly, but it's been discussed.

What I remember from the previous discussions is that it's entirely possible, but YouTube's compression algorithm essentially alters the color data to a point where we just can't decode it. It's ruined.

We're stuck using black-and-white for the moment as it stands up against YT's compression algorithm very, very, well.
>>
>>51282956
what about _pure_ red, green, or blue?
>>
>>51283224
I guess you could probably use more than one shade of each, like 50% red or 100% red, that should be possible to decode.

So:
white: 0
black: 1
50% red: 11
100% red: 1111
50% green: 00
100% green: 0000
50% blue: 111
100% blue: 000

etc, could save a bit.
>>
>>51283224
Sorry, I'm too stupid to bother reading older threads, I'm just shitposting my own opinions based on my own opinions.
>>
>>51283308 >>51283297
Oh nevermind, are you still there?
please respond
>>
>>51283224
>>51283297

Couldn't answer you for sure, but it's the color (channels?) themselves that are being ruined. No matter what you do with the color it'll come out, for lack of a better word, broken.

But I could be totally wrong and someone that really knows what they're doing can come and correct me.

>>51283308
Shitpost away. It could help people to come up with new ideas.
>>
>>51283308
<3 Haven't read a single one of them since they were going on. I just remember bits and pieces and go from there.
>>
>>51283342
If you had RGBA without any compression you could store a lot of data since you have 0-255 in each of those channels.

But even with the compression you should be able to tell the difference between the colors and their intensity and by using a scheme like >>51283297 you could probably lower the filesize by 30%.
>>
>>51283390
It's possible, but it's also possible that a lot of the data could be ruined by YT's compression.

We'd need to find a way to properly encode/decode with color data as well and test it out to see if it works. There may have been a way posted in one of the original few threads, but I really only recall people talking about how it wouldn't work.
>>
>>51283425
No worries, I'll reread the threads before shitposting again.
>>
>>51283446
Thanks. If you have the time, could you make a few notes about anything interesting that you read?

It'd help expand the FAQ and so I don't go on repeating the same shit all the time (which may not even be right.).
>>
>>51283425
Time to #fork
>>
>>51283472
You should reread all the shit if you're going to make all the threads. You're actually devolving the butterfly that the method had become into a shitty caterpillar.
>>
>>51283510
I planned to at some point here, but there's things to do and textbooks to read.

The current method works exactly as the main method we ended up with during the (4th or 5th?) threads. After that there wasn't much development other than possibly using subtitles/audio for metadata which still needs to be looked into.

Annnd now I've got side tracked and forgot what I was writing about... anyway, yup.
>>
Read through the first two original threads. Updated the FAQ with some information to cover some more info.

http://pastebin.com/SFiPjjh7
>>
File: Screenshot 2015-11-10 21.20.06.png (115 KB, 1083x600) Image search: [Google]
Screenshot 2015-11-10 21.20.06.png
115 KB, 1083x600
Got the 36 core AWS running finally

Doing about 20MB (encode) every 30 seconds so working it out I would get about 2.4GB an hour

oddly not maxing out any of the CPU's compared to the 16 core test.
avg 277 fps

I was getting about avg 150fps on the 16 core.
>>
File: upload.png (2 KB, 1047x30) Image search: [Google]
upload.png
2 KB, 1047x30
nice upload speed
>>
>>51284895
actually using a wav file might have been a very bad example since theres not much "data" in it despite the size.. entire segments in the video are black lol

its quite interesting to watch data from a visual perspective.
>>
>>51284895
Damn, now I'm very impressed. Considering Schillserver could offer close to, or even better, performance than a single 36-core machine then 1TB of encoded data is totally realistic to achieve.
>>
Tried git-cloned your repository, seems like some files, like
misc.Logger
and
files.FileInput
are missing, or I'm missing something.
>>
>>51286953
They're in this repo. https://github.com/Valkryst/Utilities

Add it as a module.
>>
>>51266054
Error: Could not find or load main class core.Driver

Anyone else? Or is it my JDK?
>>
>>51287325
Very interesting. Which OS and version of Java are you using?
>>
>>51287333
Linux

openjdk version "1.8.0_45-internal"
OpenJDK Runtime Environment (build 1.8.0_45-internal-b14)
OpenJDK 64-Bit Server VM (build 25.45-b02, mixed mode)
>>
>>51287351
Hmm... it should work, in theory. It was compiled with JDK 8_60, but that shouldn't cause much of an issue.

Can you post the full error log?
>>
>>51287375
That's all I get when I run it, verbose and all.
>>
>>51287409
Hmm... that's pretty difficult to debug then. Is it reported in error_log.txt or in the console?
>>
>>51287437
Console, there is no error log. Even if I create it with 777 it isn't populated. Wish I could give you more.
>>
>>51287456
Would you be willing to talk VIA email and/or Skype after exchanging over email?

I don't have an active Linux installation to test the program with, so I'd be sending you new versions to test and that after I finish decorating this gingerbread house.
>>
>>51287493
Sounds good, are you the email in the README?
>>
>>51287605
Yup!
>>
>>51287320
Thanks, got it to compile.
>>
>>51287834
I'm impressed actually. I didn't think many people would figure out how to compile it.

No probs!
>>
File: qr-combined.png (983 B, 350x350) Image search: [Google]
qr-combined.png
983 B, 350x350
>>51283224
>>51282848
I did it first
Take 3 frames, A, B, and C
Make a frame α where
α[r] = A
α[g] = B
α[b] = C

Here's a tip: thresholding on the RGB channels will keep YouTube's color space fuckery at bay
>>
>>51288479
Have you figured out how to get your method working with FFMPEG, or at-least working to generate the QR codes from datastreams which can then be combined with FFMPEG?

I assume the latter since you've got an example image.
>>
aren't there a million more efficient ways to do stenographic file storage in youtube videos?

http://keyj.emphy.de/real-steganography-with-truecrypt/
>>
>>51288923
Probably. This is just for fun, more-or-less.
>>
>>51288930
ah that's cool.

was about to suggest you guys abandon the qr code ideas and just start sticking files directly into webms or mp4 containers and uploading those to youtube, that would definitely increase efficiency across almost all steps.

>smaller filesize
>less video to create, encode and decode
>less time spent doing all these steps.
>>
>>51289007
YouTube transcodes anything you upload. The only way to store data there is with a highly inefficient process like the one being used.

Even if we assume YouTube would turn a blind eye to it, this is not and will never be a viable method for storing or sharing binaries.

Children are getting hyped over it because it's the first time they are discovering binaries can be encoded in other formats, like audio, video, images, or text.
>>
>>51289007
But would it actually work? Well... hmm... I don't really see why it wouldn't work, but I don't know if you can literally just stick the data of a file within the header and footer (if there is one) of an mp4 container.

>>51289069
Yeah. It's just really something that I find fun to screw around with. Sure, I could see it being practically used in some situations, but not right now and I don't see it as being anything all that useful in most situations right now.
>>
File: 1352768561156.png (76 KB, 550x430) Image search: [Google]
1352768561156.png
76 KB, 550x430
>>51282275
Your anger is absolutely delicious.
>>
>>51289007
The QR code effort is entirely separate from the main effort. It was just an example.

>>51289069
>The only way to store data there is with a highly inefficient process like the one being used.

The single-node encoding and decoding is inefficient; that's why Schillserver is in the works.
If groups set up decent clusters, the viability of its use becomes much greater.
Plus, Schillserver can be configured use a cluster to encode real video to a real format, provided the original format is amenable to being chopped up.

Besides, unused CPU time is wasted CPU time :^)
>>
I enjoy following your progress, Schillanon; keep it up!
Thread replies: 101
Thread images: 13

banner
banner
[Boards: 3 / a / aco / adv / an / asp / b / biz / c / cgl / ck / cm / co / d / diy / e / fa / fit / g / gd / gif / h / hc / his / hm / hr / i / ic / int / jp / k / lgbt / lit / m / mlp / mu / n / news / o / out / p / po / pol / qa / r / r9k / s / s4s / sci / soc / sp / t / tg / toy / trash / trv / tv / u / v / vg / vp / vr / w / wg / wsg / wsr / x / y] [Home]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.
If a post contains personal/copyrighted/illegal content you can contact me at [email protected] with that post and thread number and it will be removed as soon as possible.
DMCA Content Takedown via dmca.com
All images are hosted on imgur.com, send takedown notices to them.
This is a 4chan archive - all of the content originated from them. If you need IP information for a Poster - you need to contact them. This website shows only archived content.