Mozilla considers H.264 video support after Google's WebM fails to gain traction - Page 2

I fluctuate between Safari and Chrome but mostly end up using Safari because it "feels/Is" faster to me.

Safari is the #1 browser where I work but Chrome and FF aren't far behind each with about 17% a piece.

Open source did take over the world - except just in embedded places where users and beneficiaries never see it. But I feel your pain (and I'm sure you and your fellow ixers have the technical ability to keep overcoming).

Meanwhile, in other reportage omissions, besides XP users frozen in the Jurassic age, what is (formerly big, bad, object of AI-reader scorn) MS up to? They're on that chart, they're in the middle of their biggest internal re-invention in years, on a system encompassing tabs and phones as well as still having a 95% share in big biz PC's (a lot of PC's) and they're barely mentioned in passing in the article and the thread.

My how the worm has turned. But can anyone shed any light on what all this means to Win 8, WOA and Win Phone 8? Taken all together they're still a big piece of the market.

And I just read this:

Microsoft will offer two IE10 flavors in Windows 8 on x86/x64 devices: A Metro-Style, touch-centric IE10 and a non-Metro-Style Desktop IE10. If you need to run plug-ins, you’ll need the Desktop version, since Microsoft has decided not to allow plug-ins in the IE10 Metro-Style browser. On Windows 8 on ARM (WOA) devices, Microsoft is

not allowing plug-ins at all with IE10, so there won’t be but there still will be an IE Desktop version. ...

Other browser makers — Mozilla and Google — have both said recently they intend to build Metro-Style Windows 8 versions of their respective browsers.

I guess it runs in the family - Mozilla is some sort of descendent of Netscape, isn't it?

didya hear the one about the two skydivers with only one parachute? the guy with the parachute (who also paid for the drop flight) said to the other: "don't worry, you jump first, and i'll catch up with you ..."

For me, Firefox was buggy and prone to have memory leaks. Went to Safari also.

haha, good one.

There is nothing 'legally grey' about the H264 codecs you have on Linux. It's an open standard that anyone can implement, it is free for non-commercial use, and it will stay this way until after the patents expire. For commercial use, x264 actually has a licensing program sanctioned by MPEG-LA. If you have an NVidia card, it will even have full H264 decoding built into the drivers on Linux.

What you are saying is exactly the kind of FUD that Google used to try and foist an their own inferior codec onto the world, even though it is extremely likely to infringe on many other video codecs (you simply cannot make a video codec without doing so with the current state of the art in video encoding, it's all based on the same principles). There are no legal problems with H264, unless out of principle, you refuse to pay a very small licensing fee if you make money from products that use it.

The fact that the whole world already standardized on H264 since at least 6 years ago, and every cheap Chinese knock-off phone or MP3 player supports H264 should be enough evidence that all this fear mongering about the MPEG-LA sending black choppers to your home if you decode a video using x264 on Linux, is nothing but a fantasy story. It didn't happen with MPEG1, it didn't happen with MPEG2, it didn't happen with MPEG4 (DivX), and it won't happen with H264.

Myself, I'll gladly pay the $0.02 or similar amount added to my $700 smartphone, if that means the creators that invented H264 and all the video coding technology from the last 20 years it builds on, still have a reason left to invest in the next generation video-codec (H265 is already in the works).

Looking forward to the day when there will no longer be the question whether your player/plugin is able to play the video you're trying to watch. Digital video is like one of the most heterogenous contents in IT and it's a bloody nightmare still. A viable standard has to be found and implemented, across all platforms, if they want to digitize TV and get John Doe to buy his movies online anytime soon. iTunes is leading the way at the moment, but that doesn't mean that this will be the standard to stay.

Speaking of H.264 recently TV torrent uploaders have switched from AVI to H.264 for the simple reason it's common while offering better quality in a smaller package. Yet many of these torrenters are up in arms about the switch. The biggest issue seems to be because they can't burn it and play on their DVD player. Personally I think that's ridiculous on many levels.

• http://www.theverge.com/2012/3/4/284...rmat-x264-xvid

Minor correction: they didn't switch from AVI to H264, but from DivX/XviD (=MPEG 4) to H264, and dropped the AVI container in favor of MP4 (which confusingly does not have to hold MPEG-4 content). AVI is a container, not a video codec. The reason they dropped it in favor of MP4, is because the latter has wider support by various hardware devices (e.g. the PS3 only groks MP4).

Most of the ripped video content you'll find on the internet was H264 in an MP4 or MKV container already by the way, so in practice, not much has changed, just some guidelines that have been made 'official' for people involved in the scene.

Mea culpa. You're absolutely right.

And nobody is asking the key question... when will Moz rev gecko to support h.264? Someone mentioned end of the year... that seems to me WAY too long.

Not to mention that I think there can be another avenue... pass the video decoding to the OS. I never understood why this was never considered... or what makes it a "wrong" choice.

Minor correction:

If the "product that uses it" is a website that distributes video content out to the mass consumer, then your statement is true: commercial web broadcasters need to pay MPEG-LA a license fee to distribute video files containing H.264-encoded data; non-commercial web broadcasters can distribute video files containing H.264-encoded data free of charge.

If the "product that uses it" is a software package that takes H.264-encoded data as an input, and provides a decoded video as an output, then it falls into one of two categories:

(1) It might pass the job of decoding off to a lower layer OS or hardware service, in which case the lower-layer component will be responsible for paying the license fee, or

(2) It might ignore any lower-layer OS or hardware services, and do the decoding by itself. In this case, the software product itself will be responsible for paying a license fee to the MPEG-LA. All such software would be subject to such a licensing fees, regardless of whether or not that software is "non-commercial".

Note that MPEG-LA claims to have authority to triple-dip on its pool of patents -- pay to manufacture the hardware and/or software which is capable of encoding H.264 in the first place, (possibly depending on if non-commercial) pay to distribute the resulting H.264-encoded file to a consumer, and pay to manufacture the hardware and/or software which is capable of decoding H.264 video.

Only one of those three stages (the middle one) is covered by MPEG-LA's exemptions for non-commercial uses.

As I understand it, the grey legality of ffmpeg is due to the fact that ffmpeg is distributed without associated patent licenses for the technologies it implements. Therefore, it is up to the people who incorporate the ffmpeg library in their own software to produce a working product, to make sure that they have independently acquired any necessary licenses.

Other than the issue of patent licenses, I haven't heard anybody claim that ffmpeg had any other potential sources of grey legality.

[edit] Apparently, there was exactly one instance where the organization which owns ffmpeg was directly accused of intellectual property violation. When a group of ffmpeg developers decided to leave the project and set up their own rival fork, one of the departing developers claimed copyright ownership of ffmgeg's lightning-bolt logo. ffmpeg responded by changing their logo. [/edit]

Google got around that grey legality by purchasing its own H.264 license. Google pays the MPEG-LA a royalty fee for every copy of ffmpeg it distributes within a copy of Google Chrome.

I'd like it if Firefox switched to Webkit too, then we could have Mozilla, Google and Apple working to further the same code-base. They could sell their browser experience on plugins, UI, performance etc.

On the codec front, it's an ideal world where everything related to the web is license-free but the technology behind H.264 takes a lot of research and the boffins who come up with the algorithms have earned their reward just as they will with H.265.

Apple similarly deserves a license fee for Webkit but fortunately they make the bulk of their revenue elsewhere so they can serve the greater good by working on it for free.

This move by Mozilla will make HTML5 video authoring much easier.

As I've read it, they have to decide whether they are willing to introduce a break in compatibility for older versions of Windows.

Windows 7 includes an H.264 decoder as a built-in part of the main system libraries, so every copy of Firefox which runs on Windows 7 can hook into that capability to decode H.264 movies without needing to worry about the possibility of violating any patents.

Older versions of Windows (such as Windows XP) do not necessarily have that capability built-in. So there is no guarantee that Firefox would be able to hook into such a capability when it runs on older versions of Windows.

This leaves Mozilla with some pretty deep soul-searching questions:

- How much longer do they continue supporting Windows XP and Windows Vista? (Vista also included an H.264 decoder, but the interface was different than it is on Windows 7 and its apparent successors)

- If they do continue supporting one (or both) of these operating systems, are they willing to allow a feature as integral as HTML Video behave differently, on the same version of Firefox, simply because of the version of Windows on which the browser is running?

- Firefox is cross-platform, and currently they ensure that all versions of Firefox targeting Linux (for example) have complete feature-parity, by bundling all the necessary libraries and decoders into their own binary package. Are they willing to abandon this concept, and leave it up to a crap-shoot to determine if Firefox on Linux Box A will continue to behave similarly to how it behaves on Linux Box B?

If they start embedding an H.264 decoder right inside the browser itself, then they will need to pay license fees - something they haven't been willing to do up until now.

If they start relying on the OS or hardware to supply H.264 decoding, then they will be left with different behaviour, for the same version of Firefox, depending on which particular combination of OS and hardware components the user has chosen to install in their particular computer -- something they haven't been willing to do up until now.

On the Android front, which is where they are focusing their efforts to start out, they are in a much better position. They are guaranteed to have an H.264 decoder, fully paid-for, on every single Android device out in the wild. Perhaps some versions of Android will include H.264 decoders with different sets of capabilities, but at least a certain lowest common denominator is always guaranteed to be there.

h.265 is coming very soon, and strangely this article does not even mention it in passing...

"I mentioned it!" Skil said, as he jumped from the crowd with his hand raised. "I sure hope that HEVC is universally accepted. I'm even fine with it being forced down companies' throats even if they didn't originally want it," he finished, controversially.

Yeah, it's just common sense. If Apple had standardised on QuickTime [yes, it's a container, not a format etc] say, and Google H.264, then Google would have "won".

WebM from Google was just an a-hole move and well, you reapeth what you soweth.

Because most users are still on old versions of IE that don't support HTML5. Advertisers don't want to include fallback flash code as this just complicates things and forces the site to download more resources, slowing the page down and making delivery problems more likely. I assume ads will go to HTML5 eventually, but that's years away.

So ads don't work in HTML5 - that's got to be a big advantage over Flash!

The real war should not be on a technology. Luckily it seems the best technology has won.

The real war should be on royalties and licensing fees on a technology that has become all pervasive.

Quite conveniently, the QuickTime format was chosen to be adopted, largely unmodified, as the basis of the MPEG-4 Part 12 base media container. From that starting point, the MP4 file format, the 3GP file format, and many others, were derived.

Therefore, it is fairly safe to say that the vast majority of industry-standard computer-file implementations of the H.264 video codec are, in fact, essentially encapsulated within the QuickTime container format.

 

 

Odd. I watched it on YouTube using HTML5 and WebM. I don't think you achieved what you wanted to achieve.

 

 

These ones:

 

http://blog.webmproject.org/2012/03/webm-gaining-momentum-in-hardware.html

http://blog.webmproject.org/2011/01/verisilicon-and-webm-support.html

http://www.design-reuse.com/news/24961/dual-hd-video-ip-core-vp8.html

http://www.youtube.com/watch?v=YcsfOMbfix8

 

 

No it isn't. If and when Mozilla adds H.264 decoder support they'll be paying millions of dollars a year just to support their Linux users. H.264 decoders must pay a licencing fee. H.264 encoders must pay a licencing fee. Web videos that carry a charge for access also must pay a licencing fee for the act of viewing the video (yes, the licencing really is that absurd). The licence costs also vary according what the end user is permitted to do with H.264 video created with a particular device. If you have a video camera with H.264, read the H.264 end user licence that came with it sometime. It's quite restrictive.

 

You really should at least read the H.264 licencing summary from the MPEG-LA: http://www.mpegla.com/main/programs/AVC/Documents/AVC_TermsSummary.pdf

 

Here's the relevant part as far as software encoders and decoders are concerned: "For (a) (1) branded encoder and decoder products sold both to End Users and on an OEM basis for incorporation into personal computers but not part of a personal computer operating system (a decoder, encoder, or product consisting of one decoder and one encoder = “unit”), royalties (beginning January 1, 2005) per Legal Entity are 0 - 100,000 units per year = no royalty (this threshold is available to one Legal Entity in an affiliated group); US $0.20 per unit after first 100,000 units each year; above 5 million units per year, royalty = US $0.10 per unit. 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."

 

H.264 licencing is messy and complicated. To describe it as "free for non-commercial use" is to deeply misconstrue and misunderstand the licencing realties.