Closed Bug 541286 Opened 15 years ago Closed 12 years ago

MPEG2 support for HTML5 <video>

Categories

(Core :: Audio/Video, enhancement)

Product:
Core
Component:
Audio/Video
Platform:
x86
Windows XP
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: BenB, Unassigned)

References

(
URL
)

Details

Please support MPEG2 and MPEG4 with H.264 in <video>, on typical systems.

Reasons:
- 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
<http://youtube-global.blogspot.com/2010/01/introducing-youtube-html5-supported.html>
- 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
We have no plans to support patent encumbered codecs. If H.264 becomes unencumbered, we will consider adding support.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
> 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.
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.
Shaver made a convincing argument.
<http://shaver.off.net/diary/2010/01/23/html5-video-and-codecs/>

(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.)
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.
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.
Ian, YouTube supports WebM, and Firefox supports that natively now (bug 559052), so that reason is now void, luckily.
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.
As Shaver notes in http://www.theregister.co.uk/2010/08/26/mozilla_on_h264/, this is not actually a change at all. Merely an extension of the status quo.
DUP bug 714408 with patches
More a dep than a dup. bug 714408 is just about android/b2g.
Depends on: 714408
Since this has been reconsidered since it was closed, should it be reopened?
This is resolved by the gstreamer support added in bug 422540
See bug 799318 for tracking bug on supporting H.264 on desktop. Android and B2G have support in nightly for H.264 already.
Depends on: 799318
No longer depends on: 799318
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 12 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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.
Changed title to reflect this is for implementing MPEG2 as H.264 is covered by other bugs as mentioned in comment 29.
Summary: MPEG2 and MPEG4/H264 support for HTML5 <video> → MPEG2 support for HTML5 <video>
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.
roc explains very clearly why we wouldn't do this on Brendan's blog: https://brendaneich.com/2012/10/html5-video-update/#comment-13220
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → WONTFIX
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
Summary: MPEG2 support for HTML5 <video> → MPEG2 and MPEG4/H264 support for HTML5 <video>
(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.
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.
Summary: MPEG2 and MPEG4/H264 support for HTML5 <video> → MPEG2 support for HTML5 <video>
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.
(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.)
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.
"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.
All I'm asking for is that the "blacklist" is implemented as pref, not hardcoded in C++.
(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.
Thanks.
You need to log in before you can comment on or make changes to this bug.