HandBrake 1.2.0 Released
handbrake.fr
handbrake.fr
But not sure why this is on front page today, as it has been released almost a month isn't it?
Since you're familiar with the project's development, would you mind clearing some of this ambiguity up for me? Thanks.
Note that HB uses a release (4.1) rather than git master HEAD. So, some of those patches may get rescinded with new ffmpeg releases.
Also, it's best to think of ffmpeg as having two parts: the libraries (codec, format, ...) and the API controller which sets up the processing pipeline and manages its run i.e. parsing the commnad line, registering input/output streams, and executing the required operations. The latter for ffmpeg is in fftools/. Handbrake implements its own top-level controller.
There's a very visible quality drop when streaming with NVENC, but that's realtime.
I encoded 1250GB~ of Star Trek: The Next Generation Blu Ray's to 355GB of H.265/HEVC video, and I feel the result speaks for itself https://i.imgur.com/VklppOK.jpg
FWIW. Running the file through an i7-4790 would take roughly 4 1/2 hours
A GTX 1000 series does it in 4 minutes
Gold standard for H.264 quality/encode time/bitrate is still x264 medium / slow.
For H.265, the situation is much different. x265 is far from as mature as x264 and frankly the licensing is such a mess that it looks like H.265 might actually lose the war of next generation codec. Instead VP9 -> AV1 seems to be the industry’s codec of choice with adaption from Google, Twitch and Facebook. Also note Apple is back on the AV1 page.
Fast forward 10 years and basically every single laptop has hardware accelerated H.264 encoding through Intel's QuickSync FFHW and desktops have it through Nvidia. On top of that the software encoder (x264) is so fast that it's possible to do it in realtime on a CPU.
There is a fair chance that VP9 will see the exact same pattern here. Today CPU encoding is unfeasible, as you've noticed. However Intel is releasing VP9 encoding on their QuickSync encoder with newer CPU's and Nvidia will from my guess have it either 1 or 2 GPU generations from now. Same goes for AV1 here.
It's also interesting too think that the age of these aggressive improvements in CPU speed we've had over the past 14 years (from 2005) might come to an end, where efficiency instead comes from specialised hardware, such as fixed function hardware doing encoding on the chips, as NVENC/QuickSync does today. I don't know if realtime AV1 encoding will be feasible on a consumer grade CPU within the next 10 years, but i sure know it's hardware counterpart will be.
Of coz that is if you care about quality and retaining film grain that sort of things. Otherwise Hardware encoder from Nvidia is pretty good ( No idea about Radeon, but it seems Intel still doesn't care about encoding quality, they only care about speed. )
Pro-world also uses transcoders, and not everyone likes/is able to use Adobe for that.
Yes. Why wouldn't it be?
This is also interesting: https://offthetracksmovie.com/
(Interesting factoid: the same person spearheaded and designed all of FCP, FCPX, and Premiere)
Do anyone know who won the fight of this fork?
I say that because mpv is one of the projects that mostly use parts of FFmpeg internals and also one of the first projects to use modern futures (and deprecate older versions too).
I'm surprised it took handbrake so long.
Of those downstreams who ever switched to libav, most have switched back to ffmpeg, incl Debian and now Handbrake. The development of libav slowed to essentially a halt with next to no activity in their git, and their latest release was 11 months ago, while ffmpeg had two major releases (4.0, 4.1) and numerous point releases in that period.
libav, in my humble opinion, also suffered from NIH where they sometimes - with what looked to me like religious zealotry - insisted on doing stuff own their own, while ffmpeg at the same time happily merged tons of changes from libav. This gave ffmpeg, in addition to their brand recognition and associated network effects, yet another advantage.
It also didn't help that libav created a lot of bad publicity for themselves, starting with them trying to take over ffmpeg in a hostile manner initially instead of forking, or when their debian packages (maintained by a libav member IIRC) started telling users that ffmpeg is "deprecated". Or when one of their folks sent ffmpeg a "cease and desist" letter claiming copyright of the logo they had been using for quite a while, insisting ffmpeg stop using it. (That's why libav still uses the 2d zigzag logo, while ffmpeg switched to a 3d zigzag one).
This describes the entirety of the libav initiative from birth to death. Good riddance.
http://www.macobserver.com/tmo/article/directly-rip-and-conv...