Hi guys!
Longtime lurker here.
As part of my graduation project, I'm trying to develop a (web)tool which should make video encoding a lot easier and faster. It's actually a follow up to my previous research, in which a lot of (pro) participants stated that time is often a limit to quality. This tool should provide the best settings based on time and hardware, but it's possible to get settings without those parameters as well. After learning some basic PHP skills, I've completed the base code and I think I need to share it first, before I continue to develop the tool any further. Let me know what you think and most importantly: don't be gentle!
You can view the tool here: link and if you've got any spare time, please provide some feedback in this topic or at the form below the website.
I know there are some issues regarding 4K encoding advice (didn't properly implemented a VP9 algorithm yet), but please any feedback is welcome!
Thanks!
-Jon
Fixed some minor issues:
Still hoping on some feedback guys, it'll be much appreciated.
Love the tool, however is there a way for the tool itself to detect our upload speed. Or barring that I recommend putting a small link to one of the many pages online that detect it.
On the drop down for websites you should have vimeo and vimeo pro, because pro will soon support 4k and regular free vimeo is still only 720p.
Thanks a lot!
I added Vimeo Pro/Plus support, I only have to limit the framerate output to max. 30fps for Vimeo yet.
You can calculate the upload speed with the tool (just click the 'calculate' button next to the input field). It uses the speedof.me HTML5 API, but if the results of the calculation aren't correct or unreliable, I may just add a link to speedtest.net or something similar indeed.
Again, thanks for your feedback and keep it coming!
-Jon
Deadline category should also have the option to be in terms of hours. Rarely measured in minutes.
Thanks, added a dropdown menu with minutes/hours selection to the feature request list.
I've implemented improved Vimeo support; V0.21.3:
Feature Requests:
Known Issues:
Feature requests or general feedback are still welcome!
Hey Jon de zwaan =)
-- EDITED --
I just realized that other than creating the preset your page also can work as a bitrate calculator, duh. NICE!
BTW, I guess the fact that handbrake dropdown option is unavailable it is probably a future implementation...
Also very high bitrate videos take (cue) longer for YT grinding machine to ingest
In my particular case I normally outpuke videos with a lot of debris and grain... so I have opted for x264/x265(tortoise) slow seasoning. Right now exporting a 720p version for vimeo from HB; 10 Mb with this settings:
ref=10:weightp=1:subq=10:rc-lookahead=10:trellis=2:bframes=16:b-adapt=2:direct=auto:me=umh:merange=64:analyse=all:
deblock=-2,-2:psy-rd=1.0,0.25:aq-strength=0.5:no-dct-decimate=1:deadzone-inter=6:deadzone-intra=6:ipratio=1.1:
pbratio=1.1:qcomp=0.8:vbv-maxrate=12000:vbv-bufsize=12000
But I admittedly know nothin' bout the subject, just follow the recepees in the dealers cookbooks :P
Hi Maxr!
Thanks, yeah Handbrake with x264 has a lot more options compared to Adobe, so discovering an algorithm for optimum settings takes quite a while and will probably take a lot of concessions ;-) I don't think the output of the tool will be as detailed and extensive as your presets, because a lot of those settings really depend on your source footage. But a nice topic you've got there, will dig into your settings soon.
Cheers!
+1 for Handbreake - it's so much nicer with way smaller size (or really, really better at the same size). I encode 90% of my webcontent with Handbreake. Don't know if this is even possible, but can we have a button that sitches from data level (full swing) to Broadcast (studio swing) input?
And yeah, thank you so much for doing this :-)
Thanks Frank! Still working on Handbrake implementation, and as far as I know you can't control colorspace in Media Encoder itself, maybe Handbrake will let you, but haven't looked at it yet.
V0.21.4:
Feature Requests:
Known Issues:
Say hello to HandBrake!
V0.3
Feature Requests:
To do:
Known Issues:
As you might know, the tool is still in development and every form of feedback, or even just testing a couple of settings, can contribute to improve it (and I desperately need it for my thesis, so much love for those who take a minute.)
Thanks!
Good work Jon!!!
Maximum file size restriction (also accounting for audio headroom as HB presets only tweak video) would be super nice option... say one doesn't want to encode a YT video at 50Mbps, but still wants optimized bitrate for a determined size. BTW could not import into HB the downloadable ".plist" file; pasting the settings worked fine.
Looking forward x264... and thanks =)
Good program, Jon.
Just going a little bit out of thread (and I can open a new one if needed): this calculations are made for a finalized file to be reencoded with Adobe Media Encoder / Handbrake, I guess?
It is because I've calculated in your program a 5 min video, 1080p, 24 fps, for Youtube, Core i7 or similar, with Adobe Media Encoder; the profile shown is very similar of the one I use - it is even "heavier", 50 Mbps CBR, I use 40Mbps VBR; the filesize is a little bit larger than the similar files that I render in Premiere CS6 (in general my resulting files are 1Gb, in the calculator is 1,3Gb). Everything looks very similar to my real using.
Except the encoding time: in the calculator, the result was 00:05:29; in my Premiere Pro, to render this clip (with single instance of FilmConvert, little EQ in sound, and nothing more), my machine takes more than an hour (a Core i7 4970k, 16 Gb ram 1866mhz, GTX 960 card enabled in Premiere, program in SSD, caches in one HDD drive, sources and exports in a second HDD drive). Is it normal?
my machine takes more than an hour (a Core i7 4970k, 16 Gb ram 1866mhz, GTX 960 card enabled in Premiere, program in SSD, caches in one HDD drive, sources and exports in a second HDD drive). Is it normal?
If you're rendering from an already clean master (with no lumetri, effects, ramps, grain, etc.) no it's not normal. Not even HB or hybrid with "veryslow" x264 preset would take so long. With such hardware config should be pretty pretty fast, probably faster than realtime. I don't cuda/nvdia but remember reading something about editing text files in Premiere and AME in order for them to support some GPUs... dunno, maybe some issue with the codec?
@jondezwaan sorry for carry on off topic
Jon are you planing x264 for HB only or AME also?
BTW did if somebody cannot manage to put AME encoding x264s ( I had that issue for a long time) it helped that inside ~/Library/Preferences/Adobe/Adobe Media Encoder to delete all folders - of course back up before, just in case.
Thanks for the kind words and incredible useful feedback guys!
@maxr Maximum filesize is already available under the 'Preferences' menu (gear icon in the top right corner). Audio is definitely at my to do list, other users asked for it as well, but video calculation has priority right now, as the're still some bugs floating around unfortunately. I'm aware of some circumstances the *.plist file won't import into Handbrake, especially on Apple computers, will try to fix that ASAP. I wasn't aware of the possibility to encode x264 in Media Encoder, will take a look at it sometime! Thanks for your support and feedback!
@MarcioK The tool calculates coding time based upon a fully rendered digital intermediate like Prores or DNxHD as a source file. It's impossible to calculate coding time with a (unrendered) source coming directly from a NLE timeline, because the tool cannot detect what kind of effects or raw material is being used. Great to hear though results are somewhat correct in comparison with real life tests. VBR filesize is rather hard to calculate, as it's using a smart algorithm to save bits from less complex scenes and frames and use them on more complex scenes in terms of motion and detail. So filesize calculation with a VBR will never be accurate unfortunately, but I will try to implement it in the future nonetheless, as VBR is extremely useful to keep bitrates high and filesizes low. Thanks for your feedback!
@bmorgan83 Thanks! My only Apple device is a rather ancient 2008 Macbook, without a recent version of Compressor, so I will have to find a way to calculate coding times for recent Apple computers. I'll put it on the feature request list. Thanks again!
I'll try to keep developing the tool in my sparetime, but I have to finish my thesis as well, so development will slow down in the coming weeks, sorry about that.
Cheers!
It looks like you're new here. If you want to get involved, click one of these buttons!