Future VP8 / VP9 support in Handbrake?
Future VP8 / VP9 support in Handbrake?
Hello guys. I apologise if this have been discussed somewhere else but doing a search did not return any results.
Do the Handbrake guys have plans to incorporate VP8/VP9 seeing that Google and Mpeg LA guys have come to a agreement to keep these two codecs license free?
Do the Handbrake guys have plans to incorporate VP8/VP9 seeing that Google and Mpeg LA guys have come to a agreement to keep these two codecs license free?
- JohnAStebbins
- HandBrake Team
- Posts: 5712
- Joined: Sat Feb 09, 2008 7:21 pm
Re: Future VP8 / VP9 support in Handbrake?
VP8 is unusably slow, has limited device support, and sub-par quality (IMO), so I have no plans to use it personally. Therefore, I have no incentive to do this work. One of the other HandBrake developers spent some time on a patch to enable libvpx (https://reviews.handbrake.fr/r/316/). But it hasn't been worked on for about 8 months.
This is a case where I believe a well written patch contribution would be considered, but there is currently little interest on the HandBrake team in expending much time on this.
This is a case where I believe a well written patch contribution would be considered, but there is currently little interest on the HandBrake team in expending much time on this.
Re: Future VP8 / VP9 support in Handbrake?
OH ok. That is a pity ... was hoping there would be at least plans for VP9 seeing that it is aiming to go head to head with H.265 and to even out perform it and be a free codec at the same time
I hope this changes in the future.
Be that as it may....I love Handbrake. Keep up the good work Mr. Stebbins
I hope this changes in the future.
Be that as it may....I love Handbrake. Keep up the good work Mr. Stebbins
Re: Future VP8 / VP9 support in Handbrake?
If they come up with a faster encoder, it would be a lot more interesting… whether VP9 can go head-to-head with H.265 at the same encoding speed remains to be seen (unlikely with libvpx, IMO).
Re: Future VP8 / VP9 support in Handbrake?
VP9 is still early doors, so I wouldn't expect a viable encoder for some time yet. It's something I'll probably test when it matures a bit.
I did the initial prototype of libvpx in HandBrake and while it worked, as john said it was insanely slow. My motivation after that dropped off the cliff pretty quickly.
My ultimate goal was ditching theora and using vp8/9 in it's place. Theora is going to get the chop at some point, but I want a viable replacement first.
Maybe someday, but probably not someday soon.
I did the initial prototype of libvpx in HandBrake and while it worked, as john said it was insanely slow. My motivation after that dropped off the cliff pretty quickly.
My ultimate goal was ditching theora and using vp8/9 in it's place. Theora is going to get the chop at some point, but I want a viable replacement first.
Maybe someday, but probably not someday soon.
Re: Future VP8 / VP9 support in Handbrake?
Thank you S55. At least you are showing some interest in VP9 .... so it is a not a definite no then
Re: Future VP8 / VP9 support in Handbrake?
VP9 would have to catch up to the current H.264 encoder first, which seems to be a long way off.ockie wrote:OH ok. That is a pity ... was hoping there would be at least plans for VP9 seeing that it is aiming to go head to head with H.265 and to even out perform it and be a free codec at the same time
Re: Future VP8 / VP9 support in Handbrake?
There is a point of diminishing returns in the compression vs. quality wars -- h264 has already hit it, at least for the time being, and is destined to become a keystone in the evolution of video encoding, as was MPEG-2.
VP8 was ridiculous in the 'claims vs. performance' paradigm, and VP9 equally so, by all indicators. Short answer, Google blew it. h265 is an unknown quantity, but any claims of a 50% file size reduction over h264 are to be held highly suspect. Even h264 actually delivered only about half that "claimed" percentage over MPEG-2 in the real world.
These outrageous unsubstantiated claims of halving the file size, and then halving it again at a given unprovable quality, were either made by the worst liars (those with an agenda), or . . . well, three blind mice.
End of rant.
VP8 was ridiculous in the 'claims vs. performance' paradigm, and VP9 equally so, by all indicators. Short answer, Google blew it. h265 is an unknown quantity, but any claims of a 50% file size reduction over h264 are to be held highly suspect. Even h264 actually delivered only about half that "claimed" percentage over MPEG-2 in the real world.
These outrageous unsubstantiated claims of halving the file size, and then halving it again at a given unprovable quality, were either made by the worst liars (those with an agenda), or . . . well, three blind mice.
End of rant.
Re: Future VP8 / VP9 support in Handbrake?
Good rant thought and so right!!
Re: Future VP8 / VP9 support in Handbrake?
There's really no reason to think of HEVC as an unknown quantity. The reference encoder is slow, but you'll find that it performs quite well and can at least go toe to toe with x264 at half of x264's bitrate.musicvid wrote:h265 is an unknown quantity, but any claims of a 50% file size reduction over h264 are to be held highly suspect.
What makes you say that? With my own tests, AVC's claim of 50% reduction versus MPEG2 seem remarkably on the dot, as folks back then couldn't have predicted all the optimizations and tricks developers have added to encoders through the years. With 1080p material, x264 should range from 40% of ffmpeg's mpeg2video size (at ~CRF30) to 50% of its size (CRF20).Even h264 actually delivered only about half that "claimed" percentage over MPEG-2 in the real world.
Currently, partially optimized VP9 (it has a lot of intrinsics/assembly) is about twice as fast as completely unoptimized HEVC reference. Quality ranges from nipping at HEVC's heel to slightly worse than x264 (lacking bframes REALLY hurts VPx in some instances). Whether this is a good or bad sign is not up to me to decide.Rodeo wrote:whether VP9 can go head-to-head with H.265 at the same encoding speed remains to be seen (unlikely with libvpx, IMO).
Are you sticking with Theora mainly for speed? It's quite a bit worse than VP8 in terms of subjective quality. In objective terms with HVS metrics and aggregated over several 1080p test clips, Theora is about equal to ffmpeg's mpeg2 at x264 CRF30-level 'quality' and improves to be roughly equal to xvid at x264 CRF20-level 'quality' (these were measured in terms of the bitrate needed to match x264).s55 wrote:My ultimate goal was ditching theora and using vp8/9 in it's place. Theora is going to get the chop at some point, but I want a viable replacement first.
(I do have results for the claims above. Will likely post on Doom9 once VP9's bitstream is finalized.)
Re: Future VP8 / VP9 support in Handbrake?
Your expectations seem a bit fanciful, but you are entitled to all the self-validation you wish to pursue. And Doom9 is the right place for that.
A 20% compression improvement over x264 by either of these codecs would be impressive at street level, and would get quite a bit of attention. We'll see.
A 20% compression improvement over x264 by either of these codecs would be impressive at street level, and would get quite a bit of attention. We'll see.
Last edited by Deleted User 13735 on Thu Mar 28, 2013 2:26 pm, edited 1 time in total.
Re: Future VP8 / VP9 support in Handbrake?
No. Theora is also slow and there is no disputing it's all round worse than vp8.Are you sticking with Theora mainly for speed?
Re: Future VP8 / VP9 support in Handbrake?
You're comparing x264 with ffmpeg MPEG-2 source? Who does that? How could one even tell a difference?With 1080p material, x264 should range from 40% of ffmpeg's mpeg2video size (at ~CRF30) to 50% of its size (CRF20).
In any production environment, a 30% compression advantage over native HDV is called a good day.
That's about all I have to contribute to this discussion.
Re: Future VP8 / VP9 support in Handbrake?
Misunderstanding here: Raw i420 sources (combination of Derf and JCT-VC). Mulitple x264 encodes off raw. Multiple MPEG2 (and others) encodes also off raw. Compared Bjøntegaard deltas using piecewise cubic on HVS-relevant metric batch, namely multiscale SSIM and PSNR-HVS-M.musicvid wrote:You're comparing x264 with ffmpeg MPEG-2 source? Who does that? How could one even tell a difference using that source?With 1080p material, x264 should range from 40% of ffmpeg's mpeg2video size (at ~CRF30) to 50% of its size (CRF20).
Your production environment has its own needs, and I'm not going to argue with that. However, I was demonstrating and quantifying (as much as these can be quantified) perceptual differences between encoders at rates from streaming-like to near-transparency, which is an exceedingly relevant region to me and, I'd assume, a massive number of other folks. If you have data points from your end of the spectrum, please feel free to present.In any production environment, a 30% compression advantage over native HDV is called a good day.
This got unnecessarily tense. Here's a panda.Your expectations seem a bit fanciful, but you are entitled to all the self-validation you wish to pursue.
Re: Future VP8 / VP9 support in Handbrake?
Your source conveniently omits the x264 settings used. Slow x264 down to the speed of HEVC and see how it compares.xooyoozoo wrote:There's really no reason to think of HEVC as an unknown quantity. The reference encoder is slow, but you'll find that it performs quite well and can at least go toe to toe with x264 at half of x264's bitrate.musicvid wrote:h265 is an unknown quantity, but any claims of a 50% file size reduction over h264 are to be held highly suspect.
Also the choice of bitrate can be used to skew the comparison. At high enough bitrates, everything is fine.
- JohnAStebbins
- HandBrake Team
- Posts: 5712
- Joined: Sat Feb 09, 2008 7:21 pm
Re: Future VP8 / VP9 support in Handbrake?
This just made my day. Thanks.xooyoozoo wrote:This got unnecessarily tense. Here's a panda.
Re: Future VP8 / VP9 support in Handbrake?
Both of those links are mine. Sorry that the first doesn't include in-depth settings; it was originally made to be linked through another post (that already had settings).mduell wrote:Your source conveniently omits the x264 settings used. Slow x264 down to the speed of HEVC and see how it compares.
You'll find another link to the relevant settings in through 2nd link up there: http://privatepaste.com/82e5c8e646
I entirely agree with that, but the statement can also apply to any other codec within the past 2 decades: when you're not limited by disk space and bandwidth, you can even spare the excessive bitrate to even use something like motion-JPEG for your Skype and YouTube streams. Right here right now, that's definitely not universal, and in a world where encoders are still defined by its quality per bit, why not push things to find their actual quality per bit? What is progress if you don't use it?mduell wrote:Also the choice of bitrate can be used to skew the comparison. At high enough bitrates, everything is fine.
Edit: I didn't realize that this was going to be contentious. I'll bow out now.
Re: Future VP8 / VP9 support in Handbrake?
So your x264 settings were 10x faster than HEVC? Or 100x?xooyoozoo wrote:Both of those links are mine. Sorry that the first doesn't include in-depth settings; it was originally made to be linked through another post (that already had settings).mduell wrote:Your source conveniently omits the x264 settings used. Slow x264 down to the speed of HEVC and see how it compares.
You'll find another link to the relevant settings in through 2nd link up there: http://privatepaste.com/82e5c8e646
There's no sense in these comparisons unless you're only varying one thing.
Re: Future VP8 / VP9 support in Handbrake?
[Message removed by user]
But thanks for the cute Panda. Now I gotta learn how to grow bamboo . . .
But thanks for the cute Panda. Now I gotta learn how to grow bamboo . . .
Re: Future VP8 / VP9 support in Handbrake?
+1JohnAStebbins wrote:This just made my day. Thanks.xooyoozoo wrote:This got unnecessarily tense. Here's a panda.
Re: Future VP8 / VP9 support in Handbrake?
That would still be awfully slow, unless I'm mistaken?xooyoozoo wrote:Currently, partially optimized VP9 (it has a lot of intrinsics/assembly) is about twice as fast as completely unoptimized HEVC reference.Rodeo wrote:whether VP9 can go head-to-head with H.265 at the same encoding speed remains to be seen (unlikely with libvpx, IMO).
Either way, we're not against either VP8/VP9 or H.265. It's not a very high priority just yet though.
-
- New User
- Posts: 2
- Joined: Mon Mar 28, 2016 3:39 pm
Re: Future VP8 / VP9 support in Handbrake?
First off to the developers a big Thank You for Handbrake. Off topic but use ffmpeg to reduce file size with nvenc_h264, nvenc_hevc, and vp9 after it is first made perfect with Handbrake.
Anyway I too would really like to see VP9 and Opus audio in Handbrake. I can get near perfect 1080P video / 5.1 channel audio that stream beautifully with that codec combo in file size less than a GB. Takes me about 2.2GB to get same quality with HEVC for the time I am willing to spend transcoding.
Anyway I too would really like to see VP9 and Opus audio in Handbrake. I can get near perfect 1080P video / 5.1 channel audio that stream beautifully with that codec combo in file size less than a GB. Takes me about 2.2GB to get same quality with HEVC for the time I am willing to spend transcoding.
-
- New User
- Posts: 2
- Joined: Mon Mar 28, 2016 3:39 pm
Re: Future VP8 / VP9 support in Handbrake?
H.265 painfully slow in Handbrake but it's available. And next to no setting adjustments available. (The 42hr transcoding I'm doing now is on a 4.8GHz i7 4790K. With ffmpeg nvenc_h265 I can get it done in 15 minutes two pass llHQ but there is no NLmeans or slower preset. So I take the time if I need to really clean up my source before further complex filtering in ffmpeg.) So not sure if others would agree but basic settings for VP9 is all I need. Biggest qp, two pass, select number of cores to use, and to able to use NLmeans and remove grain. Speed would be in distant future since no one really to my knowledge offers VP9 hardware encoding yet except high end Intel hardware and some Samsung phones.Rodeo wrote:That would still be awfully slow, unless I'm mistaken?xooyoozoo wrote:Currently, partially optimized VP9 (it has a lot of intrinsics/assembly) is about twice as fast as completely unoptimized HEVC reference.Rodeo wrote:whether VP9 can go head-to-head with H.265 at the same encoding speed remains to be seen (unlikely with libvpx, IMO).
Either way, we're not against either VP8/VP9 or H.265. It's not a very high priority just yet though.
Re: Future VP8 / VP9 support in Handbrake?
LOLtheonlycure wrote:Anyway I too would really like to see VP9 and Opus audio in Handbrake. I can get near perfect 1080P video / 5.1 channel audio that stream beautifully with that codec combo in file size less than a GB. Takes me about 2.2GB to get same quality with HEVC for the time I am willing to spend transcoding.
Re: Future VP8 / VP9 support in Handbrake?
Hahah, so true.These outrageous unsubstantiated claims of halving the file size, and then halving it again at a given unprovable quality, were either made by the worst liars (those with an agenda), or . . . well, three blind mice.
Just as you'd be a fool to trust someone else's eyes, you'd also be a fool to trust Peak SNR and Structural Similarity tests, and who knows about that VQM tool that everyone quotes regarding x265.
So, the question is: how DO you objectively judge filesize/bitrate vs quality?
Short of having a fixed IEEE review panel of professional eyeballers, it literally is "what do YOU think looks good". This instantly makes all claims meaningless as any questioner would take those claims out of the context of that other person's perceptions.