Mozilla Considers H264 After WebM Fails To Gain Traction 182
HerculesMO writes with word that "Looks as though Mozilla is considering using H264, one step closer to unification of a single protocol for video encoding. It's a big deal for HTML5 traction, but it still leaves Google holding onto WebM." The article, though a bit harsh on Ogg Theora, offers an interesting look at the way standards are chosen (and adopted by the browser makers).
In Other News (Score:5, Funny)
Re: (Score:2)
Or on Android.
Joke post?
Flash is currently installed on my Nexus One.
Re:In Other News (Score:5, Funny)
Re: (Score:3)
Re: (Score:2)
Yes, but it will only be officially supported for up to and including 4.x. After that, Android will be Flash-free, too.
That's why they came up with data URI's. Bless their souls. ;-)
Realmedia codec (Score:5, Interesting)
Re:Realmedia codec (Score:5, Informative)
People figured out that Real (and Realplayer) were utter pieces of garbage and stopped using them?
Same thing I wish would happen to quicktime.
Re: (Score:2)
Quicktime isn't a codec, really.
Maybe you want the Quicktime Player to die, and on Windows maybe it's not needed - the fact that it is necessary for iTunes is merely because it's cross platform and Quicktime is a core component of OS X.
I'm not sure what Apple's goals with Qucktime Player are - version X is a step backwards from version 7 on OS X, and I keep both installed concurrently and prefer to use v7 where possible.
To bring it back to the topic - Quicktime Player can play any codec you have a plugin fo
Re: (Score:2)
Quicktime X does have a few advantages over previous versions. The main one being the UI when playing a movie, as long as you don't mouse over the window there are absolutely no window decorations, just the video, which is really useful for those of us with large screens (both in physical size and resolution) who like to tile our windows and keep TV shows or movies running while doing other stuff.
I kind of wish VLC or MPlayer OSX Extended would implement this.
Re: (Score:2)
I kind of wish VLC or MPlayer OSX Extended would implement this.
Try MPlayerX. I think you'll be pleasantly surprised. The current version doesn't have a playlist or individual loop feature, but that's really about the only things it doesn't have, IMO. It does a reasonable attempt at detecting episodic files in a folder.
Re: (Score:2)
Hell try
> mplayer
from MacPorts.
Re: (Score:2)
Easy - it's time for a rewrite. QuickTime, like Final Cut Pro and Logic before it, was getting somewhat crufty and time to start anew. Apple generally likes to introduce a stable brand new version of the software first, then re-add back missing features (we see this happening with Final Cut). OS X was another such "victim"
Re: (Score:2)
Thing is, no sane person uses the Quicktime codec anymore so talking about it makes no sense. It's like saying you want Real to die, it's already dead, stop beating that damn horse already.
Apple themselves use MPEG-4 almost exclusively, it's pretty much their standard format for video and has been for years.
Re: (Score:2)
Well, except for the fact that there are still a lot of quicktime movies out there, and that Apple itself forces Quicktime installs on Windows machines when you try and install iTunes.
Quicktime sucks (the app). Thankfully, Win7's Media Player can play Quicktime movies natively. As long as you don't have to install iTunes (and being forced to is the main reason I'm looking to dump my iPhone), you can have a decent OS unpolluted by the utter garbage that is the QuickTime app. Oh yeah, and iTunes is utter g
Re: (Score:2)
You do know that iOS is moving towards "PC-free" which means you won't need any software on your PC?
Re: (Score:3)
Moving toward... but not there yet. Doubt they'll get there before WP8, and Android is already mostly independent. Regardless, my experience with iTunes and QuickTime are enough to make me want to avoid all Apple products in the future. The iPhone itself is nice enough, I guess, but definitely limited (and becoming boring/stagnant).
I'm still looking forward to an Apple-free future, even if it's not quite here yet for me.
Re: (Score:2)
Quicktime isn't a codec, really.
.qt, .mov
Quicktime movies.
It's a codec, your post is like saying "WMV isn't a codec, Windows Media Player can play any codec you have a plugin for." The software and the codec have a similar name. Back when Apple was viciously proprietary about the spread of their QT codec, it would only play in the stupid Quicktime Malware plugins.
You're still wrong, but good attempt at trying to correct me. .mov is a container format that can contain (duh!) any number of different codecs and streams.
Again, "back when Apple was viciously proprietary" the codec of choice inside Quicktime containers (.mov) was probably Sorenson.
Just to be clear: the .mov format is a container. It can contain many different codecs (and has always done, and continues to do).
If I ask you what codec your file uses and you tell me it's a .mov file then I do not have enough
Re: (Score:2)
Very much like that, actually. Have you had to use them? They're nowhere near as nice or well behaved as native apps...
Oh, I agree. Native is the way to go, but it's hardly the first example of a weakly-ported app, but they're usually poor in the Win > other platform direction.
My point was that it's still cross platform, if not the most shining example.
Re: (Score:2)
For the most part quicktime movies are being replaced by MPEG4. This makes sense, since the MPEG4 container is heavily based on the Quicktime movie container. As for the CODECs, well if you use popular MPEG4 codec then you should be fine.
Re: (Score:2, Interesting)
My quick fix is to change the extension. Rename .mov to .mp4 and BAM over 90% of files suddenly work on the other players I have.
Re:Realmedia codec (Score:5, Funny)
they are all still buffering...
Re: (Score:2)
Omg. I literally exploded when I read your comment. :)
Re: (Score:2)
they are all still buffering...
But when they're done buffering, they are going to be ZOMG SO AWESOME!!!
(yes, THREE exclaimation points of awesome - it's a scientific fact.)
Re: (Score:2)
People got sick of Real invading their OS's, and burrowing so deep into them it was impossible to remove without reformatting.
Lol editors (Score:5, Informative)
Yes, you already posted the story [slashdot.org] about this in March. Which is the same month when the linked article is from. Good to see timithy is still at the top of his game!
Re: (Score:2)
Better than samzenpus, like yesterday! Timothy, at least, tries.
Dupe, old news, vanity link (Score:5, Informative)
Dupe:
http://news.slashdot.org/story/12/03/13/2027215/mozilla-debates-supporting-h264-in-firefox-via-system-codecs
http://yro.slashdot.org/story/12/03/20/1742209/mozilla-to-support-h264
Old news:
March 13th, 2012 -> This particular blog's story is March 16th, 2012 -> Today is April 26th, 2012
Vanity link:
It's a link to AppleInsider--why on earth would AppleInsider be a novel or interesting source about internal Mozilla strategy?
Dear editors: wake the hell up.
Re: (Score:3)
Slashdot is following the normal media company business model: sell the same material over and over.
And us here bitching about it are actually helping them, with increased "participation" statistics and click throughs. Aren't media companies wonderful?
Kind of serves them right really (Score:5, Insightful)
Mozilla wouldn't even have to taint itself by supporting it. Just hook the video tag to the media framework in the host OS - Quicktime, DirectShow, gstreamer etc. and invoke the default h264 codec if its present and suitable or point the user at a way to obtain it if it isn't. They could still ship Theora with the browser if they wanted.
Re:Kind of serves them right really (Score:5, Insightful)
h264 is ubquitous. It's really stupid to deny the reality that people want to use it because of politics which is what it boils down to.
The aren't denying reality, they were trying to shape it.
And I'm glad they tried, even if they didn't win this time.
Re: (Score:2)
And so was Gif, and we know how that went...
"Still used all over the web"?
Re: (Score:2)
Just hook the video tag to the media framework in the host OS
Browsers have been able to do that for years and years and it still doesn't work properly.
Horseshit. <embed> worked a decade ago and it works today.
H.264 is a terrible solution (Score:5, Informative)
Here's a pretty good article:
http://www.zdnet.com/blog/bott/a-closer-look-at-the-costs-and-fine-print-of-h264-licenses/2884 [zdnet.com]
from the article:
To use and distribute H.264, browser and OS vendors, hardware manufacturers, and publishers who charge for content must pay significant royalties—with no guarantee the fees won’t increase in the future. To companies like Google, the license fees may not be material, but to the next great video startup and those in emerging markets these fees stifle innovation. []
Re:H.264 is a terrible solution (Score:5, Insightful)
The article is an Apple troll.
Re: (Score:2)
This company did not raise prices for their older MPEG1, MPEG2, or MP3 standards, so why do you think they'll suddenly turn evil?
Re: (Score:3)
This company did not raise prices for their older MPEG1, MPEG2, or MP3 standards, so why do you think they'll suddenly turn evil?
"..."
Re: (Score:2)
>>>>>This company did not raise prices for their older MPEG1, MPEG2, or MP3 standards, so why do you think they'll suddenly turn evil?
>>
>> "..."
That's what I thought. You've got nothing accept fear, uncertainty, and doubt. I am not persuaded that I should distrust MPEG.
Re: (Score:2)
You probably don't have any doubts about CISPA [slashdot.org], either. There's no way anyone will run afoul of that, since the powers behind that can be counted on to never turn evil.
This is why, in a word-association game, the sane response in to "trusting" is "fool".
Re: (Score:3)
This company did not raise prices for their older MPEG1, MPEG2, or MP3 standards, so why do you think they'll suddenly turn evil?
The MPEG LA has quite often raised the price for H.264. The MPEG LA's H.264 license summary [mpegla.com] talks about past license increases. The royalty cap has increased since 2005:
The maximum annual royalty (“cap”) for an Enterprise (commonly controlled Legal Entities) is $3.5 million per year 2005-2006, $4.25 million per year 2007-08, $5 million per year 2009-10, and $6.5 million per year in 2011-15.
The MPEG LA's H.264 license FAQ [mpegla.com] specifically addresses their approach to increasing license costs:
Q: Is there a limitation on the amount that royalty rates may increase at each renewal?
A: If royalty rates were to increase, they will not increase by more than 10% at each renewal for specific license grants.*
*Annual Royalty Caps are not subject to the 10% limitation
Re: (Score:2)
The fact that one company owns the license to this technology and makes no guarantees to _not_ increase licensing costs means that once h.264 support is the be-all end-all solution to web video, this one company has a monopoly on the sole video technology that drives the web. Most people running windows/mac have probably indirectly paid for licensing fees for h.264 multiple times. Nice racket they've got there and nobody is complaining, yet.
Here's a pretty good article:
http://www.zdnet.com/blog/bott/a-closer-look-at-the-costs-and-fine-print-of-h264-licenses/2884 [zdnet.com]
from the article:
To use and distribute H.264, browser and OS vendors, hardware manufacturers, and publishers who charge for content must pay significant royalties—with no guarantee the fees won’t increase in the future. To companies like Google, the license fees may not be material, but to the next great video startup and those in emerging markets these fees stifle innovation. []
This is why Mozilla will just pass H.264 along to whatever decoder the OS has available and not bundle H.264 into Firefox at all. This position makes the most sense for them and the users. Every device I use already has a H.264 decoder with hardware support. I just need Firefox to get out of the way.
Re: (Score:2)
That smacks a little of FUD.
The purpose of the royalties are to provide a continuing and stable revenue stream to those who have put resources into developing it and thus the goal is to ensure wide adoption of the standard so that it gains traction and ubiquity. Punitive fees that "might increase in the future! oooh scary!" runs counter to that goal. If people stop using the format because it is expensive and difficult to implement then the revenue stops flowing in.
Just because it is a licenced standard wit
Re: (Score:2)
Once the format is the only one used, and is burned into all hardware, good luck migrating off of that anytime soon. So they could make a lot of money by increasing licensing fees a couple of orders of magnitude, and that's exactly what they will do if they think they can make more money that way.
...and then all future devices will drop it for an alternative. With the speed that hardware turns over presently it would be foolish to assume you had total control and that your users had nowhere to go.
That's the whole point. You want to make it affordable and attractive so that you maintain your revenue stream. Assuming you're in a position of dominance you don't try to kill the goose that lays the golden eggs. Then you have a dead goose and no more eggs in the future.
Re: (Score:3)
One company doesn't own the license. The MPEG-LA is a 3rd party clearinghouse for people to set up patent pools. They don't own H.264 or the patents. H.264 is 'owned' by the ISO/MPEG standard boards and the companies that hold the essential patents.
Re: (Score:2)
...with no guarantee the fees won't increase in the future
That's rather misleading. There actually are guarantees that the rates won't increase before the end of 2015 (they're even spelled out in the article you linked, as well as the original Terms Summary [mpegla.com] provided by the MPEG-LA). In addition to those guarantees, there are also guarantees that when they set new rates for the five-year period starting in 2016, the new rates will be no more than 10% above the current ones. Besides that, previous major standards the MPEG-LA have controlled haven't been abused in t
Re: (Score:2)
Re: (Score:2)
The justification for WebM (Score:5, Insightful)
The justification for WebM is that it would allow people to freely share videos using your own infrastructure without charge and without additional cost.
It's not about the consequence for the consumer, it's about the chilling effect it has on free culture.
It has HUGE consequences. Mozilla knew that, that's why they tried to play hardball.
Re:The justification for WebM (Score:4, Interesting)
Is there any reason they have to choose a side?
No seriously, why can't they have both h264 and WebM support and let the market decide which one gets used more?
Re: (Score:2)
No seriously, why can't they have both h264 and WebM support and let the market decide which one gets used more?
The market has already decided that, hence the decision. If WebM is removed from official builds then anyone should still be free to re-include it in their own builds. Doesn't really seem like an issue either way.
Re: (Score:2)
No seriously, why can't they have both h264 and WebM support and let the market decide which one gets used more?
The market has already decided that, hence the decision. If WebM is removed from official builds then anyone should still be free to re-include it in their own builds. Doesn't really seem like an issue either way.
That is cold comfort to those who want to publish video in WebM format.
Re: (Score:2)
That is cold comfort to those who want to publish video in WebM format.
Alas, the avalanche has already started. It is too late for the pebbles to vote. [wikiquote.org]
Re: (Score:3)
The WebM support is not going anywhere. The discussion is about adding H.264 alongside.
As for the other... there are tons of non-market forces involved. For example, if all browsers have H.264 support, then standards bodies will likely start requiring H.264 to be the codec used for various things (see WebRTC, for an example where this could happen).
Worse yet, once something is in a standard you run into the fact that in many countries following certain standards in certain situations is required by law.
An
Alternative? (Score:2)
Re: (Score:3)
It's not that it's arcane, it's that it's boring. It's a whole lot of very, very boring work to develop a good video codec. It's the kind of thing open source development is very bad at.
So no, there isn't one.
Re: (Score:2)
Re: (Score:2)
There are plenty of metrics for video quality already, which are in wide use when developing these things.
But the problem is that there are so many things you can do, and so few of those are actually good. Developing these things requires a huge amount of trial-and-error. And you can't just do a change and run a quick test to see if it made things better, because if you just test against one thing, you will over-optimize for that particular case at the expense of every other video.
It's hard work with frustr
Re: (Score:3, Insightful)
Yes, it really is that hard. I've written some of these things. It's not that the knowledge is inaccessible: most of the concepts involved are covered in a good undergrad discrete math course. It's just that 99.999% of the programmers out there either don't take the course, or forget what was taught the moment after the final is handed in.
Look at the sorry state of linux audio, for one. Layer upon layer, library upon library, everyone's an architect slinging metaphors and objects around but very few act
Re: (Score:2)
Re: (Score:2)
Sure. Go ahead, let us know how it goes.
Re:Alternative? (Score:5, Interesting)
I suspect the bigger problem is that there are so many patents on video codecs that any better open source alternative would infringe on at least one of those patents.
This is a controversion question. The consortium which licenses H264 has certainly expressed this opinion. They say things along the lines of: "we can't say on which of our patents it infringes but we know it must because 1) it is a modern video codec, and 2) one cannot possibly write a modern video codec without having to deal with at least some of our patents."
The view is expressed by the developers of VP8 (WebM) is that H264 is the result of deliberately steering developement so as to intersect as many of the consortium's members' patents as possible. VP8 is supposedly the result of heading toward the same goal while steering around them.
Whether the VP8 developers can make their codec as good as H264 without involving any of the MPEG consortium patents is still an open question. I gather that they have not achieved that goal yet.
Don't bother reading TFA (Score:5, Insightful)
TFA is not worth your time. He says all sorts of outrageous stuff as if it were fact: apparently he knows exactly what Google was collectively thinking when it introduced WebM, for example.
And the ending is sort of surreal. Hooray! The patent-encrusted H.264 has defeated the challenge by the free and open software! Here are my wrists; there's still room for a couple more handcuffs, put them on! (Eh, probably not a fair summary, but about as fair as his treatment of Google.)
steveha
Re: (Score:2)
TFA is not worth your time. He says all sorts of outrageous stuff as if it were fact: apparently he knows exactly what Google was collectively thinking when it introduced WebM, for example.
His comments on Google "getting away with" a clean room implementation of Java on Android are pure flamebait.
Re: (Score:2)
Here's to hoping that "Fair, Reasonable and Nondiscriminatory" licensing fees stay that way.
Re: (Score:3)
Superior in what way? Certainly not in terms of licensing. And there is no guarantee that h264 doesn't infringe on patents.
Phillip.
Re:open standard yes, open source no. (Score:4, Informative)
There's plenty of open source encoders and decoders available. ffmpeg, x264 (produced for VLC) to start.
The notion that H.264 is not "free" isn't a result of a development methodology, it's because people think that somehow patents make it that way, despite the fact that the software authors have no choice in the matter.
Re: (Score:2)
What other than patents is it?
If we abolished patents how would this not be a free standard?
Re: (Score:2)
Re: (Score:2)
Did they even get past the proposal evaluation part?
Re: (Score:2)
So in other words we're following the Star Trek Rule here...
Re:open standard yes, open source no. (Score:5, Insightful)
The notion that H.264 is not "free" isn't a result of a development methodology, it's because people think that somehow patents make it that way, despite the fact that the software authors have no choice in the matter.
H.264 is not free-as-in-freedom nor free-as-in-beer, and patents are the reason. IP amounts to copyright, trade secrets and patents, but the first two don't apply here. It's a patent issue.
Re:open standard yes, open source no. (Score:5, Insightful)
H.264 is not free-as-in-freedom nor free-as-in-beer, and patents are the reason. IP amounts to copyright, trade secrets and patents, but the first two don't apply here. It's a patent issue.
No. It's a licencing issue. H.264 is not an open, royalty-free standard and that's what makes it bad choice for the web. VP8 is covered by patents but it's licenced under royalty-free terms. If H.264 was licenced under royalty-free terms for all use cases then there would be no issue.
Re: (Score:2)
If patents really define what makes software "free" or not-free, then no one would be able to chose to make a free H.264 codec.
My point is it's stupid to not support a codec just because of how it was invented. It's still free software.
Re:open standard yes, open source no. (Score:5, Insightful)
If patents really define what makes software "free" or not-free, then no one would be able to chose to make a free H.264 codec.
I am not sure what you are trying to say. One can certainly write H.264 codec and distribute the source code under the GPL. But the recipient does not have the right to _use_ it unless he obtains a license. So, these implementations are not fully free and the authors cannot make them free (without offering to pay the license fees for all of the users).
My point is it's stupid to not support a codec just because of how it was invented. It's still free software.
At present no H.264 implementation _can_ be free software. If you use it for certain purposes or at a certain volume you have to give money to the MPEG consortium. You may think this is OK, but it is not "stupid" to be unhappy with this arrangement.
Re: (Score:2)
As a web developer you could just use MPEG2 for videos. That will soon be free to use.
Re: (Score:3)
Re:open standard yes, open source no. (Score:4, Insightful)
Parts of MPEG-2 (AAC, for one) were not published until 1997, and some hardware codec chips might have patents that were filed much later. Similarly, there may be patents on algorithm optimizations that were filed much later, e.g. patents on ways to use pixel shaders to perform some part of the MPEG-2 decoding process. So although the format will ostensibly become free and clear of patents four years from now in its barest reference implementation, that does not necessarily mean that you can't get sued if you write your own implementation. :-)
Re: (Score:2)
But this is true of any codec. You could patent an optimization for WebM just as easily as you could patent an optimization for H.264.
Re: (Score:3, Informative)
The thresholds for encoders/decoders are based on distribution quantities, not revenue thresholds. Below 100,000 units, there is no royalty fee owed. Between 100,000 and 5 million units, the cost is 20 cents per unit. Above 5 million, the cost is 10 cents per unit.
The maximum royalty fee owed is currently capped at $6.5 million.
Part of the license agreement specifies that the fees can't increase more than 10% per 5 year period (2011-2016 is the current period). The max cap can go up more than 10% per period
Re: (Score:2, Informative)
Sure. And if it becomes the dominant codec, I guess we can pray they don't alter the deal further after 2016. Enjoy your clown suit [youtube.com].
Re: (Score:2)
Re: (Score:2)
Not necessarily, the decoder/encoder royalty fees are pretty cheap and could be sold at a good profit as an add-on for less than a buck.
Re: (Score:2)
There does appear to be a certain haphazard logic there, you must admit...
Re: (Score:2)
I bet a debian desktop will still be free from patented stuff by default, so business will have workstations that can't play videos unless explicitly authorized. A win - win scenario, if you ask me, but then, I can't stand web browsing with flash enabled and all those inane animations.
Re: (Score:3)
Soon Linux will be, depending on context, "that operating system that can't play videos on the web and doesn't support standards", or "that operating system where everyone infringes patents, so it would be crazy to use it in a business".
Both of these scenarios can be avoided by using the hardware H.264 decoding capabilities built into nearly every PC video output device made in the past 5 years. (Intel's pre-Cedar Trail Atom is about the only exception I can think of.) As long as the driver support is pre
Re: (Score:2)
Ogg Theora and WebM are no better in quality than MPEG3 (i.e. halfway between crappy MPEG2 and the newer MPEG4).
I wish ATSC used MPEG4 cause I'm tired of seeing blocks/mosquitos on my television screen. Oh well... the ATSC arrived too soon (1998).
There is no such thing as MPEG3. They went right from MPEG2 to MPEG4. I imagine they did this because they thought MPEG3 would be confused with MP3. MP3 refers to MPEG audio layer III (part of the MPEG1 and MPEG2 standards).
Re: (Score:2)
There's no such thing as "MPEG3". It's MPEG audio Layer 3.
Re: (Score:2)
Re: (Score:2)
Ogg Theora and WebM are no better in quality than MPEG3
You're comparing video codecs to an audio codec?
MPEG-3 was the brief name for high-bitrate video and audio that was eventually rolled into MPEG-2. It should not be confused with MP3 [wikipedia.org], which is really MPEG-1 or MPEG-2, layer 3 audio.
So basically, both you and the GP are confused, although Theora isn't anywhere close to H.264, especially when implemented with a good encoder like x264. VP8 is used so little that it's hard to say what the quality is like over a wide variety of content.
Also, WebM is technically the name of the container for VP8 video with Or
Re: (Score:2)
I interpreted that comments as "Ogg Theora and WebM are no better in quality than what MPEG3 might have been if there had been a codec between MPEG2 and MPEG4".
Maybe I'm just giving the poster too much benefit of the doubt?
Re:Harsh? (Score:5, Informative)
Besides, VP8 is actually more-or-less equal to H.264 in quality and compression, you can easily verify that yourself with libvpx and x264.
It really isn't. VP8's quality is comparable to that of H.264's Main Profile.
H.264 High Profile eats VP8 for breakfast in bitrate-limited scenarios, meaning
about 800 kilobit/s for SD content.
But even at around 1,5Mbit/s, it's really obvious to the trained and still visible
to the untrained eye. Yes, I actually have done double-blind tests.
vpxenc is still very young, so improvement will happen, in both perfomance
and quality. But the developers themselves have stated that it is unlikely to ever
exceed H.264 MP by much.
I've done extensive tests to try to coax better quality out of VP8, and have pretty
much failed. I even had help from one of the guys at google working on VP8.
And yes, it's part of what I do for a living.
Have a look yourself:
x264 High Profile, 790Kb/s, 4.3MiB [chewey.org]
VP8, best effort, 770Kb/s, 4.2MiB [chewey.org] (the encoder was given the same constraints as x264)
VP8 falls completely apart on high-frequency picture content, where H.264 holds up quite well.
As one of the x264 devolpers said when I showed this around (verbatim quote): "Holycrapbirds".
Of course, that low a bitrate is a very harsh test. At over twice the bitrate, VP8
still needs more bits for similar quality, but the relative difference is much smaller.
At some point around 2Mbit/s, "quality saturation" sets in.
But for sites doing lots of streaming to clients behind <1Mbit/s connections and aiming
for noncrapbird quality, this is a real issue.
Re: (Score:2)
Excellent examples.
I need to bookmark these for the next time someone claims "MPEG4 is no better than WebM"
Oh and by the way I wasn't confused about MPEG3. I am well aware that No such standard exists. I was making the point that WebM lies about halfway between MPEG2 and 4 in quality..... that WebM==MPEG3 if that standard had existed.
Re: (Score:2)
Excellent examples. I need to bookmark these for the next time someone claims "MPEG4 is no better than WebM"
Meh, I'm sorry, I didn't consider bookmarking: Those files are in /temp on my server,
where everything older than 10 days gets killed. That was stupid of me.
I've just added an exception to the cleanup script, so the URLs should survive –
but still: Feel free to save the files locally or put them somewhere else.
Re: (Score:2)
Isn't everyone using the main profile, though? So what's your point?
Re: (Score:3)
Re: (Score:3)
Re:Harsh? (Score:4, Informative)
Not that I am doubting you, but could you provide the encoding settings you used for both VP8 and H.264?
I'm on vacation until mid next week, so don't have access to the scripts used. From memory:
Both are two-pass encodes. x264 recommends single-pass with --crf nowadays, because it's
faster and nearly as good, but constant quality mode and bitrate limits don't mix too well, and
for my low-bitrate case there's still a clear advantage for longer-range precognition.
The x264 settings are a tweaked "--preset slower", with longer rc-lookahead and added
bandwidth limitations (vbv_maxrate and friends). x264 writes the exact settings used – including
an expansion of a preset into its individual parameters – at the beginning of its output, so have
a look at "strings testenc_x264.mp4 | grep x264", or use mediainfo on the file.
For vpxenc, it's basically the same, using "--good" and "--tune=ssim", adding bitrate control
settings and minor tweaks. No parameter logging in the output here unfortunately, so I can't give
you any more details right now.
The tests I have conducted myself were more-or-less of the same quality so I am curious as to whether or not I did something wrong myself.
You probably did nothing wrong at all, you just didn't restrict the encoder as heavily as I did.
I tried to make it clear that those examples are rather extreme: If you allow higher bitrates, VP8
quality improves quite a bit, and everything above about 1.5Mbit/s is fine in the vast majority of cases.
Also, the test clip used is intentionally really really hard to encode (smooth, slow-moving, weak
gradients; rotations; low contrast; high motion; high frequency; all combined; hard cuts; etc.),
to highlight encoder capabilities – and shortcomings. It stress-tests everything from motion
estimation to several other predictors the encoders may or may not have, to bitrate allocation,
so it's an excellent worst case.
I'm not trashing VP8 or vpxenc by the way, we're still going to use it to serve video to clients and/or
devices without H.264 support. It's just that H.264 (in its x264-encoded manifestation, there are lousy
H.264 encoders out there, mostly the really expensive ones) really shines in low-bandwidth use cases,
and VP8 is universally outclassed by H.264 High Profile.
Re: (Score:3, Interesting)
The videos look absolutely identical until the last part with birds, a clearly pathological case of "make benchmark to fit the product" type. In both videos the view of birds is highly distorted at the end, and no details other than a whole screen filled with slow-moving high-frequency pattern, are visible. x264 example keeps the birds distinct while VP8 blurs them, but neither provides usable details -- those videos have to be encoded at higher rate to be watchable, no matter what.
Re: (Score:2, Informative)
Wow, you couldn't be more wrong. There are many more differences between the two videos.
In the first segment (the one that lasts only 0.62 seconds), the details of the mountains. In the second segment, the blue sky as the camera passes through the mountains, and to a lesser degree the two mountains themselves. In the third segment, the details in the foam and, more evidently, in the trees far away behind the cascades.
Saying that "The videos look absolutely identical until the last part" is just ridiculous.
Re: (Score:2)
Re: (Score:2)
I do too. The thing that hurts those formats is the lack of hardware support on music devices.