Continued from previous thread.
>>51232794
-------------------------------------
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
-------------------------------------
fuck off
>>51248470
question: how long before google prohibits this on youtube?
>>51248720
No clue, but I don't see it coming anytime soon.
They most-likely won't prohibit it unless it becomes more than a little niche thing as it hardly is now.
>>51248794
If anything, you might get offered a job at Google
>>51248971
That'd be nice, but I doubt it'd ever happen. Heh...
Quick question. Do you think the buttons and text look fine?
I've been messing around with getting the buttons and text to pop out from the page a bit to improve "contrast".
>>51249035
It's not bad. Something seems off, but I don't think it's the text or buttons, more along the lines of the background.
>>51249182
The main background (see behind the Endcode/Decode buttons or the Accept/Cancel buttons) or the secondary background (see 90% of the settings menu)?
I think it almost looks as if it needs to be either brighter or darker, but I'm not sure.
I've been having second thoughts about doing all the file exchanging via HTTP.
Does have a good reason why FTP wouldn't work before I start changing the spec?
>>51250179
None that I can think of.
IIRC, FTP uses two TCP connections (one for file transfer and one for commands) so it'd still be just as useful maybe even moreso depending on how you use it.
>>51250247
Ok then.
The /f/chunk HTTP endpoint should be considered obsolete.
>>51249035
Looks good to me, can be polished a little more too.
>>51250317
I've had a thought about the chunks. They must have a filesize that perfectly fits inside of a frame with no more, and no less, data.
Only the very last frame of the resulting encoded file can be padded.
Therefore only the last chunk of the file, if it doesn't fit within the size of a frame, can be padded.
So keep that in mind when writing the code that splits the files into chunks to send off to the slaves.
Wasn't sure if we discussed that before and it just came to me.
i just noticed your project. will it have linux support?
>>51250431
EFR's Schillserver will work on Linux from what I recall.
Schillsaver also works on Linux, but it requires Java 8.
>>51250448
Any exciting new stuff? What are you working on now?
>>51251999
Not too much at the moment. I just finished a, nearly, full-rewrite of the program yesterday, so it needs extensive testing done to eliminate all of the bugs.
All that I've done today is fix up a few text fields, adjust the button/text colors, and some other simple stuff.
Not entirely sure what to work on next.
>>51250384
No, this is the first I've heard of chunk size requirements.
The current method for assigning chunks is to split a chunk in half until it meets a worker's chunksize parameter.
So if no worker supports a full chunk, it will split it in half. Provided this is a multiple of the frame size, it's fine, but I don't know how much data goes in a frame, and I imagine it varies with encoding settings.
How about instead of having to encode all the frames to an unknown size, it just adds a predefined "break" frame between encoded chunks? It would offload the work to the decoding portion (it now has to split the video based on that break frame and then decode the individual chunks).
>>51252156
Yeah, the chunk size depends on the width/height setting of the output video. You could easily write the program to split a file into appropriately sized chunks IF the smallest chunk size is the amount of data that can be held in a single frame.
I think you're on the right track with "Provided this is a multiple of the frame size". That sounds like what I mean.
>>51252225
The problem is, the height and width aren't the only FFmpeg flags. Schillserver is dumb: it just sends parts of a file and a list of ffmpeg parameters to another machine. It doesn't understand the ffmpeg parameters, that's for ffmpeg to care about. If someone set the parameters to ":^)", it wouldn't care.
As far as i can tell, We can't reliably and accurately determine the data per frame for every possible combination of ffmpeg parameters without encoding the data first, so we can't slice the data appropriately.
>>51252602
Hmm... you make a very good point.
I think the only way that we could reliably get it to work is if we don't allow the user to specify their own commands to FFMPEG.
We should use the proven commands, that I set as defaults on Schillsaver, for Schillserver.
If we do that, then we can determine the exact size of the frame and set up the rest of the process that way.
Of course we should still have the option to add more "selectable" presets of commands, so we would just need to define a fram size with each new preset that we add.
The program would just take the framesize that we specify for the preset commands, then it'd work fine.
Ehh... I'm probably rambling at this point, but you probably get what I mean.
>>51252739
I think I can accommodate that with a few modifications.
If you provide me with a list of defaults and the formulas for frame capacity, I can get started ASAP.
>>51252828
This should cover all of the information you need to know.
http://pastebin.com/FmCaRuh0
Just want to say I don't know if you changed anything but decoding is impressively fast for me now.
>>51255443
I think there was a somewhat significant increase in performance, but I haven't tested, thanks to JavaFX.
A fair chunk of the program runs on a separate thread from the main program, so it isn't as bogged down trying to output from FFMPEG while en/decoding... I think.
