Last Comment Bug 541286 - MPEG2 support for HTML5 <video>
: MPEG2 support for HTML5 <video>
Product: Core
Classification: Components
Component: Audio/Video (show other bugs)
: Trunk
: x86 Windows XP
-- enhancement with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Maire Reavy [:mreavy] Please needinfo me
: 560924 561082 570963 585763 645675 720882 733330 (view as bug list)
Depends on: 714408 759506
  Show dependency treegraph
Reported: 2010-01-21 18:55 PST by Ben Bucksch (:BenB)
Modified: 2012-12-21 18:46 PST (History)
31 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Ben Bucksch (:BenB) 2010-01-21 18:55:02 PST
Please support MPEG2 and MPEG4 with H.264 in <video>, on typical systems.

- Most sites offering video have the video already in that format. Reencoding and storing all videos in a different format is several orders of magintude more effort than just changing the webpage to use the <video> tag and stream the existing content.
- YouTube did just that
- MPEG2 is patent-encumbered, but otherwise an open standard and most widely used, in DVDs, DVB (all digital TV in Europe) etc.. I have several TB of MPEG2 videos from TV at home. Reencoding all that is unrealistic.
- See bug 435339 comment 27
Comment 1 User image Chris Pearce (:cpearce) 2010-01-21 19:48:12 PST
We have no plans to support patent encumbered codecs. If H.264 becomes unencumbered, we will consider adding support.
Comment 2 User image Ben Bucksch (:BenB) 2010-01-22 01:39:34 PST
> We have no plans to support patent encumbered codecs.

On which reason? To boycott them or to avoid patent lawsuits?
The latter can be achieved by e.g. not shipping the codec ourselves and using generic APIs like DirectShow, gstreamer or similar, or offering a codec API and allowing the user to drop in a third-party implementation. I'd rather do the latter than install Flash.
Comment 4 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2010-01-22 10:01:55 PST
Another reason is to avoid the gif disaster. Supporting a patented format, even if that can be done freely for now, can have very large costs to the ecosystem. If not to us then to our users.
Comment 5 User image Ben Bucksch (:BenB) 2010-02-04 05:09:41 PST
Shaver made a convincing argument.

(I tend to ignore patents, because I believe software patents must not exist, and there is a EU directive which says exactly that, so law agrees with me, so I like to believe that software patents simply don't exist. Even more so for mathematical / algorithmic stuff like codecs. Unfortunately, court decisions are different. I'd rather fight patents on the legal front than boycotting useful technology. But maybe I'm naive and that's the only working way in the current world situation.)
Comment 6 User image Robert Longson 2010-04-21 12:00:22 PDT
*** Bug 560924 has been marked as a duplicate of this bug. ***
Comment 7 User image Marco Bonardo [::mak] 2010-04-22 07:40:12 PDT
*** Bug 561082 has been marked as a duplicate of this bug. ***
Comment 8 User image Robert Longson 2010-06-09 07:37:37 PDT
*** Bug 570963 has been marked as a duplicate of this bug. ***
Comment 9 User image Not interested in Mozilla any more 2010-06-09 07:41:54 PDT
With people like YouTube supporting it support for h.264 is critical, your browser will go the way of the dodo. This is one bit of politics too far for Firefox. It's the final straw. I'm off to another browser. I wish you luck with your browser that can't support one of the largest sites on the internet.
Comment 10 User image Not interested in Mozilla any more 2010-06-09 07:43:29 PDT
ps. There's a . in H.264, H264 does not exist, at least not in this context. I would correct it if you want to not get lots more duplicates.
Comment 11 User image Ben Bucksch (:BenB) 2010-06-09 07:52:51 PDT
Ian, YouTube supports WebM, and Firefox supports that natively now (bug 559052), so that reason is now void, luckily.
Comment 12 User image Kevin Brosnan 2010-08-09 15:34:29 PDT
*** Bug 585763 has been marked as a duplicate of this bug. ***
Comment 13 User image Kevin Brosnan 2010-08-09 15:37:51 PDT
*** Bug 585763 has been marked as a duplicate of this bug. ***
Comment 14 User image José Jeria 2010-08-26 14:16:11 PDT
License changed now
Comment 15 User image Chris Pearce (:cpearce) 2010-08-26 14:55:22 PDT
That license change only applies to distributors of free internet video, i.e. streaming services. A patent license is still required to ship an H.264 decoder/player.
Comment 16 User image Timothy B. Terriberry (:derf) 2010-08-26 15:00:01 PDT
As Shaver notes in, this is not actually a change at all. Merely an extension of the status quo.
Comment 17 User image Ben Bucksch (:BenB) 2010-12-17 09:17:16 PST
Microsoft actually did this:
Comment 18 User image Robert Longson 2011-03-28 07:10:33 PDT
*** Bug 645675 has been marked as a duplicate of this bug. ***
Comment 19 User image Matthias Versen [:Matti] 2012-03-06 03:54:40 PST
*** Bug 733330 has been marked as a duplicate of this bug. ***
Comment 21 User image Ben Bucksch (:BenB) 2012-03-20 08:35:06 PDT
DUP bug 714408 with patches
Comment 22 User image Ralph Giles (:rillian) | needinfo me 2012-03-20 10:59:59 PDT
More a dep than a dup. bug 714408 is just about android/b2g.
Comment 23 User image Dirkjan Ochtman (:djc) 2012-07-19 04:32:21 PDT
Since this has been reconsidered since it was closed, should it be reopened?
Comment 24 User image [:Aleksej] 2012-08-27 12:30:02 PDT
*** Bug 720882 has been marked as a duplicate of this bug. ***
Comment 25 User image sam tygier 2012-09-11 04:14:49 PDT
This is resolved by the gstreamer support added in bug 422540
Comment 26 User image Matthias Versen [:Matti] 2012-10-14 19:29:07 PDT
*** Bug 801485 has been marked as a duplicate of this bug. ***
Comment 27 User image cajbir (:cajbir) 2012-10-14 19:40:13 PDT
See bug 799318 for tracking bug on supporting H.264 on desktop. Android and B2G have support in nightly for H.264 already.
Comment 28 User image Matthew Gregan [:kinetik] 2012-10-17 14:34:34 PDT
We have a bug for tracking the support we're adding, bug 799318.  That doesn't include MPEG2.  There's no need to keep this bug open.
Comment 29 User image Ben Bucksch (:BenB) 2012-10-17 15:58:44 PDT
The old argument to WONTFIX were patents. I proposed to use platform APIs to avoid the issue. That is actually happening now, on bug 799318.

As for MPEG2, see initial description. There's no reason not to allow MPEG2, at least via a config option, if we allow MPEG4 and AAC.
Comment 30 User image cajbir (:cajbir) 2012-10-17 16:07:43 PDT
Changed title to reflect this is for implementing MPEG2 as H.264 is covered by other bugs as mentioned in comment 29.
Comment 31 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-10-17 17:16:31 PDT
Yes there is. We don't add features to the web just because "there's no reason not to" or "patents doesn't prevent us from doing it".

Anything we add to the web means a looong time of commitment to keeping it working. Even when there are features and tools that are strictly better. So the cost of adding support for MPEG2 doesn't seem worth the benefit.
Comment 32 User image :Gavin Sharp [email:] 2012-10-17 19:12:38 PDT
roc explains very clearly why we wouldn't do this on Brendan's blog:
Comment 33 User image Ben Bucksch (:BenB) 2012-10-18 05:32:07 PDT
I already said that there is a big benefit from doing this: All video material from DVDs and DVB (digital TV in Europe) is in MPEG2. That's a *ton* of material - in fact most material that I am interested in watching is in MPEG2, not in MPEG4. Converting 8 TB of personal video collection, just to play it in the browser (or xulrunner), is not feasible.

df -h:
Mountpoint    Used
/dvd          1,7T
/tv           5,9T
Comment 34 User image Ben Bucksch (:BenB) 2012-10-18 05:36:02 PDT
(And, I don't think I'm the only one who keeps his video collection as lossless copy and wants to sometimes play it in the browser.)

If nothing else, please allow XULRunner apps and power users to enable MPEG2 manually. I wrote a XULRunner TV application, and I desperately need this.
Comment 35 User image :Gavin Sharp [email:] 2012-10-18 08:45:34 PDT
As already mentioned, bug 799318 tracks h264. Playing games with Bugzilla summaries isn't really going to convince anyone.

It's obvious that you're invested in this personally. Your personal video collection and TV app aside, there is nowhere near the market demand for MPEG2 as there is for h264. Making assertions based on anecdotal evidence is also unlikely to be persuasive.
Comment 36 User image Ben Bucksch (:BenB) 2012-10-18 16:49:55 PDT
What? *I* am playing games? I filed this to have MPEG support in Mozilla, both MPEG4 and MPEG2. WONTFIXing it, then filing a new bug for the same thing, then insisting on WONTFIXing it - although it does get fixed, and morphing the summary to something else - that is playing games. And that upsets me, but I've contained it so far.

It upsets me, because it shows that the decision making process around here has nothing to do with openness anymore, and more importantly nothing with ratio either. The reasons I gave in the beginning here are the *exact same* reasons that are now used to justify MPEG4. I said MPEG material (both MPEG4 and MPEG2) is widespread, and we can get around the patent issues by using platform APIs. Yet I was WONTFIXed. Now a new bug is opened, which asks for the *exact same thing*, with the exact same reasoning, and that will be fixed. The very same reasons as for MPEG4 also apply to MPEG2 - there is even more material in MPEG2 than in MPEG4 -, but they are WONTFIXed again, because the powers that be decide so. Fine. But this has nothing to do with open participation anymore.

Sorry to give you that. But you asked for it, by simply changing the meaning of my bug, and then using that to WONTFIX it.
Comment 37 User image Ben Bucksch (:BenB) 2012-10-18 16:53:56 PDT
(Sorry for that truck load, I do respect you, but accusing *me* of playing games, when I just follow established Mozilla rules of "older bug wins", that is too much for me now.)
Comment 38 User image Ben Bucksch (:BenB) 2012-10-18 17:02:43 PDT
Back to ratio: I have yet to hear a convincing reason why we shouldn't allow a power user or xulrunner app to enable MPEG2. None of the mentioned arguments - open web, testing, security - apply in such a case. Testing and security aren't serious arguments anyway, because we're using platform decoders that will be used by the user's video player, it makes no difference whether an external player loads or an internal one. I do subscribe to and agree with the "open web" argument, but the "default off, only enabled by power users via a hidden pref" takes care of that.
Comment 39 User image :Gavin Sharp [email:] 2012-10-18 17:11:28 PDT
"older bug wins" is a convention, not a rule. Tracking the work in another bug wasn't meant as a slight to you, it's just a reflection of the majority opinion re: h264 shifting towards yours over time, and not wanting to re-use bugs that have a bunch of advocacy comments in them.

"XULRunner apps" are not our core constituency, and so doing work that only benefits them means not doing work that impacts our primary focus: Firefox and users of the web. If we do get platform codec support with a blacklist of codecs, I imagine it may be easy for you to easily get MPEG2 support in your local builds, and of course you're free to do so. But Mozilla is not going to invest time in testing or adding MPEG2 support to Gecko specifically, so it doesn't make sense to have a bug tracking it.
Comment 40 User image Ben Bucksch (:BenB) 2012-10-18 17:26:06 PDT
All I'm asking for is that the "blacklist" is implemented as pref, not hardcoded in C++.
Comment 41 User image Ralph Giles (:rillian) | needinfo me 2012-12-21 13:30:16 PST
(In reply to Ben Bucksch (:BenB) from comment #38)
> Back to ratio: I have yet to hear a convincing reason why we shouldn't allow
> a power user or xulrunner app to enable MPEG2. None of the mentioned
> arguments - open web, testing, security - apply in such a case.

Bug 422540 (gstreamer playback engine) provides some precedent here. So if you "did the work" à la bug 799318#c10 to add this as a build-time switch and there was clear community demand, there's a chance the patch would be accepted if it's clear the community in question is willing to maintain it.

No one is enthusiastic about this because of the format-proliferation policy, of course.
Comment 42 User image Ben Bucksch (:BenB) 2012-12-21 18:46:37 PST

Note You need to log in before you can comment on or make changes to this bug.