Comment 13 for bug 1051559

Revision history for this message
In , Pdowling (pdowling) wrote :

(In reply to Mike Hommey [:glandium] from comment #7)
> and no, embedding gstreamer like we embed other third party libraries won't
> help. The only way it would work would be to also embed the mp4 decoder, and
> that's opening a legal can of worms.

Perhaps we're missing the point here. I realize this specific bug focuses on GStreamer but AFAIK the broader goal is (or perhaps should be?) enabling HTML5 <video> support for the most common format(s) on all platforms that Firefox supports.

Is it possible that this goal would be more easily achieved if Firefox were to use the native media frameworks for each platform, i.e. DirectShow, GStreamer and Quicktime, as Firefox mobile does with Stagefright? Would utilizing these frameworks possibly be less work than targeting a single framework that perhaps changes so often because it is trying to be everything to everybody?

On another note, has anybody engaged the GStreamer people and asked them if they are willing to work with Mozilla by maintaining a branch of their code that preserves binary compatibility for longer than they historically have to date? If not glacial pack ice frozen APIs, perhaps ice cube APIs capable of thawing every summer or so? :) There could be a ceremonial GStreamer/Mozilla ice cooler that API documents get thrown into, a bit like a time capsule :) Sorry, just a bit of mirth there!

In addition, doesn't any code base change a lot more frequently whilst getting to version 1 than it is likely to after that point? Perhaps then Mr Hommey's example in comment 6 is not necessarily representative of future development trends?

Apologies if these points are less technical and more general than is ideal. However this bug thus far has seemed to evolve in more of a discussion manner than other bugs might normally so I hope it's ok to continue that style for the moment at least.