Will H.264 Codec Support Come To Fedora? Nope.

[XorEaxEax]

Edit: and I searched a *long* time for webm encoding recommendations/tutorials.

No sorry, I think I got most of my info from irc, I recall that there was currently a big difference between using --end-usage=cq on 1 pass and two pass in terms of quality (with two pass being MUCH better), I'm assuming this is due to two pass making better choices in regards to keyframes? As I stated I'm no encoding guru. I was also given the tip to use a large bitrate value which if I recall correctly had no effect other than making sure the bitrate wouldn't undershoot the cq-level determined bitrate (bug?), so setting it to a ridicoulously high value (like I did here) was only to make sure that this would not happen. Yes documentation is a sore point with vpxenc at the moment, likely because it's in heavy development and new options/features are being added while others are being deprecated/modified.

Hopefully I'm remembering all this correctly as it was sometime in early february and my memory is not like in the good ole days. For my personal encodes I use x264 so I haven't used vpxenc since then, of course this would quickly change if I had to pay licence fees for using h264.

[Gusar]

But I was not using --end-usage=cq, I was using --end-usage=vbr to do a target bitrate encode, so what you're saying here doesn't apply. I am more curious about the other settings I used, whether I should've done something differently. Just from looking at them and trying to get an idea what they do, they look very sane. If they're not, well, misleading documentation is quite a minus point for the encoder.

Two things though regarding what you said: x264 does not need two passes for a constant quality encode. If libvpx isn't capable of that, then that's another minus point for it. Also, if one should only use constant quality and not target bitrate, then that's a minus point too. Like I said in a previous post, proper ratecontrol is very important for an encoder.

PS. By counting minus points like that, I'm not trying to bash libvpx. It's quality has improved since my last test, it's speed has greatly improved. But this is an encoder that some people want that it would take over the web. That's kinda hard when it has such shortcomings.

[stqn]

But I was not using --end-usage=cq, I was using --end-usage=vbr to do a target bitrate encode, so what you're saying here doesn't apply.

XorEaxEax was replying to me though...

Two things though regarding what you said: x264 does not need two passes for a constant quality encode.

Nor does libvpx, and I also got better results with x264 in 2 pass VBR mode than in single-pass crf mode.

Thanks for the answer XorEaxEax, I'll try to remember that for my next encode.

[XorEaxEax]

Two things though regarding what you said: x264 does not need two passes for a constant quality encode. If libvpx isn't capable of that, then that's another minus point for it.

Well libvpx don't need it either, however there was a real quality increase when using it. I know it's not needed in x264, in fact unless I'm mistaken constant rate factor doesn't work with 2 pass in x264.

Also, if one should only use constant quality and not target bitrate, then that's a minus point too. Like I said in a previous post, proper ratecontrol is very important for an encoder.

True, but I think most people encoding today targets a constant quality (--crf, -cq-level) so putting effort into making that better (which it seems the vpxenc devs are currently working on) is likely wise.

PS. By counting minus points like that, I'm not trying to bash libvpx. It's quality has improved since my last test, it's speed has greatly improved. But this is an encoder that some people want that it would take over the web. That's kinda hard when it has such shortcomings.

First off I'm not sure what you mean by 'take over the web'. h264 will not be obsolete or anything even remotely so, only fools would believe that. It has the best quality, undeniably, and it will very likely remain so. And then we have h265 on the way which will again raise the bar. However, for the typical quality of what we see on the web then vp8 even as it stands now is perfectly adequate not to mention that it is also improving with each release and it's totally free. Still those who has h264 licences and/or infrastructure/userbase built around it will likely be very hesitant to switch, however for newcomers/startups I can see webm being very interesting due to not having any licence costs.

If we look past web video, then I can't see vpx making any inroads. The warez scene will always use whats best since they don't pay a dime in licence costs, and physical media like Bluray is already tied to h264 and any successor if there ever is one will be h265 (though I doubt there will be, I think physical media other than for backup purposes is dying quickly). Webm/vpx is a 'good enough' video codec for web content and again it's totally free, this means it could easily be part of a standard since anyone can implement it in anything. In a larger scope it's existence also benefits those who prefer using h264 on the web as it means that mpeg-la hasn't cornered the web codec market and thus can't set any terms they want (and believe me, if they can they will).

[Gusar]

XorEaxEax was replying to me though...

I got similar replies earlier.

I also got better results with x264 in 2 pass VBR mode than in single-pass crf mode.

Then the encodes weren't the same size. If they are the same size, the difference between crf and 2-pass is indistinguishable.

Webm/vpx is a 'good enough' video codec for web content and again it's totally free, this means it could easily be part of a standard since anyone can implement it in anything.

What would happen if the standard mandated vp8 (or theora, which was the main proponent before Google bought On2)? Very possibly such a standard would get ignored. Because of what you say - there's already tons of established infrastructure around h264. And I don't see those companies investing in a second infrastructure just for the web.

As for startups, I already addressed that: If you want to reach the broadest audience, you need h264. So those startups would need to carefully weigh the options between limiting their potential audience or paying the h264 royalties.

[yogi_berra]

It sucks that Fedora by itself is not a usable distro, but then Fedora developers cannot be blamed for that, the US patent system is the culprit.

On the contrary. There is nothing stopping Fedora or Red Hat from buying a license for H.264 to distribute with x264 something they could easily afford to do. They choose not to.

[DaemonFC]

On the contrary. There is nothing stopping Fedora or Red Hat from buying a license for H.264 to distribute with x264 something they could easily afford to do. They choose not to.

Spending $64.47 per user on patent licenses for something they give away freely isn't going to happen.

You're more than welcome to buy them for yourself.

http://www.fluendo.com/

Or you can just use RPM Fusion like everyone else does and shut up.

[yogi_berra]

Spending $64.47 per user on patent licenses for something they give away freely isn't going to happen.

The point is he was blaming Patent law when the blame lies with Fedora's policies. But do continue to flame, it makes the community seem so inviting to new users.

[DaemonFC]

The point is he was blaming Patent law when the blame lies with Fedora's policies. But do continue to flame, it makes the community seem so inviting to new users.

If you want to buy every Fedora user a patent license that costs almost as much as a copy of Windows, I'm sure most of them won't turn you down, I just hope you have the few million dollars handy.

[Hamish Wilson]

The point is he was blaming Patent law when the blame lies with Fedora's policies. But do continue to flame, it makes the community seem so inviting to new users.

Sorry, what?

It is not just about money. Fedora strives to be a free distro. You can not be truly free if you need to pay a patent to legally redistribute your source code.

By painting it as some crass financial excuse, you demean the moral issue behind all of this.

If you want to use the codecs legally you can just pay for them yourself. It is not as if Red Hat has been asking for you to pay for anything.