Closed ProxyCell closed 6 years ago
@ProxyCell Thanks for using the project and filing this issue!
AFAIK, the only case where "optimizing" the MP4 output this way has any benefit is if the MP4 file is played directly from within a Web browser, which is not the common use case. Devices like Apple TV, Roku, etc. and servers like Plex, Kodi, etc. which stream over HTTP, don't require this optimization. If they did, the HandBrake development team would have made "optimizing" their MP4 output the default behavior years ago.
Also, the performance penalty for "optimizing" can be more than just a few seconds depending on the size of the output because, essentially, HandBrake has to write the entire file a second time.
Since adding --handbrake-option optimize
, or the shortened -H optimize
, to the command line is so easy, I don't think this is necessary.
I'll leave this open for additional comments for now but I don't plan on making the change.
Thanks for the explanation @donmelton ! I'll just stick to adding the -H then :) You are right that it will write the file again but I figured it was quite negligible.
Feel free to close this anytime. Yeah I'm still using the project with --veryquick ! I ran some stats the other day and my newer (transcoded) directory is roughly 25% of the older (raw) one.
@ProxyCell Glad to know --veryquick
is working out so well for you!
OK, I'll close this now.
Here is the HandBrake documentation on the flag:
-O, --optimize Optimize MP4 files for HTTP streaming (fast start, s.s. rewrite file to place MOOV atom at beginning)
This eases the process of streaming mp4 files over HTTP. It will add a few extra seconds to the encoding process but will not impact decoding performance or file size in any negative way.