Continued from previous thread.
>>51296294
-------------------------------------
Version 6 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/SFiPjjh7
The FAQ has beeen updated as of thread 11.
-------------------------------------
PoorCloud, possible mascot.
Okay here's a difficult question. What if I have some files that I would not want law enforcement agents to find, would I first have to encrypt them before using your tool to upload them to Youtube? Would that even work?
>>51301661
Yes, you would need to encrypt them first. Schillsaver will still work exactly the same on encrypted files.
Whoever made this is retarded. Using straight up black and white chunks to encode information is just fucking stupid--obviously shows the lack of basic DSP knowledge.
No wonder it has a horrible efficiency.
>>51301907
Improve the method and contribute to making it less retarded then.
>>51301944
Sure, I'd actually love to. Can I contact you with the email?
And also is this open source?
>>51301996
Did you even read the op?
>>51302019
Yeah, my bad.
The main problem with your system is that random noise has high frequency content and macroscopic changes that are fundamentally incompatible with the way video codecs compress information.
I'd need to do some research (I'm more familiar with 1D signals) but modifying the data encoding scheme to something more efficient that has band limiting and MPEG compression-aware codes might go a long way.
What you are doing is sort of like On Off Keying with no band limiting (think morse code). There are more advanced schemes that have higher bandwidth like PSK and GMFSK and all sorts of wonderful things. Note that this is really for 1D information so doing it on video with MPEG compression might require significant modifications.
>>51301907
yeah because video codecs don't exist.
a colorfull screen uses the same storage space as a black and white one.
what are you a queer?
grow a fucking brain m8
>>51302170
>a colorfull screen uses the same storage space as a black and white one.
I guarantee you that /dev/urandom as a video will occupy way more space than a movie would, assuming similar conditions in resolution, time, etc. Compression in video codecs are lossy, and are optimized to videography and not raw data/random-looking data. What you did by having lots of black and white pixels is completely ignoring the optimization of lossy compression and therefore won't get the highest information density as you would with engineered codes.
Trust me.
instead of piping bits as black and white pixels, you could put it on a carrier and code more information and take better advantage of compression from youtube.
>>51301996
Yup, I'd love the help.
This is open source.
http://valkryst.com/schillsaver/index.html
https://github.com/Valkryst/Schillsaver
>>51302078
...annnd you totally lost me. Sounds good.
>>51302636
I'll contact you via email soonish.
>>51302657
Sounds good.
My email system has a "Greylist", so I might not get it until ~30 minutes after you send the email. If I don't respond within an hour, then try resending.
>>51302666
sure
Great! Free file storage for muh cp!
So, what configuration format would /g/ like for Schillserver:
YAML
TOML
JSON
INI
or Ren
>>51304455
The problem with these recurring threads is that it is very easy to forget to enter one's name.
>>51304473
Haven't heard of most of those, but both INI and JSON are pretty simple to use.
>>51304473
Doesn't it save the username for you? I haven't had to re-enter mine in ages.
>>51304815
fukken json.
was tasked with converting json to xml @ work. the fuck does that even mean
>>51304880
Probably taking data stored as JSON and rewriting it as the equivalent XML format?
Example... (syntax is probably fucked)...
data {
something: val,
somethingElse: otherVal
}
<data>
<something>val</something>
<somethingElse>otherVal</somethingElse>
</data>
Odd request though. They should just work with the JSON files and save time.
>>51304815
I don't come to an anonymous Cambodian embroidery blog to post with a name. I only use this in these threads so I don't have to identify myself in some other way.
>>51304989
Got a laugh out of that. Good 'nuff.
