Bug 382267 covers the main work on the video element. This bug is for the QuickTime backend implementation.
marking wanted1.9.1? to get this in the triage queue. If this needs to be blocking1.9.1?, please mark it as so.
Chris: What do you think about this one? Is this something we should do for 1.9.1?
Yes, the plan is for 1.9.1.
Chris, I imagine that the work which has to be done here applies to all OS?
After reading bug 435339 it looks like OS X only.
Yes, OS X only.
Clint, I believe this was a mistake on your side. Reverting flags.
Is this ongoing work somewhere (on a hg branch?), or is it yet to begin?
There is ongoing work on a local git branch of Chris's video work. I hope to post a patch pretty soon.
Created attachment 347003 [details] [diff] [review] wip patch Old WIP patch--it won't even apply to the current tip. Not for review. Now that the Waveform playback patch is mostly out of the way, I'm going to come back to this and get it ready for review. Need to do at least the following: - rebase to current tip - rework to use nsMediaStream - change load handing to accept an existing channel
Created attachment 362437 [details] [diff] [review] rebased against current trunk Rebased enough of the patch to build and play video (but most other stuff is broken, seeking doesn't work, most events aren't fired). Next steps: - rewrite data handler to use nsMediaStream (might need to wait for roc's block caching work--QT wants to do overlapping reads, which would cause a huge number of range requests in the existing nsMediaStream code) - rework design to be closer to the current Ogg decoder code - write tests
Actually it makes more sense to skip the first step above until roc's block cache stuff (bug 475441?) is available, since it'll probably be a different API.
It'd be nice to be able to render: data:text/html,<video id="compass" src="http://images.apple.com/safari/welcome/media/compass.mov" width="256" height="256"> from the new Safari welcome page ;)
We've discussed this within the media team (that is, me, doublec, cpearce and mgregan) and our consensus is that there is no compelling reason to work on this at this time. It was worth working on as a fallback measure if we weren't able to ship reasonable unencumbered codecs, but that doesn't seem to be a problem now. Our primary focus should be investing in open unencumbered formats. Also, supporting Quicktime on Mac isn't that useful since, even if we supported DirectShow for Windows too, few Windows users would be able to play content in Quicktime formats, so Quicktime won't be viable on the Web for a long time. (Safari on Windows ships Quicktime with the browser, but we can't do that of course.)
BTW Apple could easily create an Ogg version of their video and include it as fallback if they cared about their content working in Firefox.
Forgive me if this is considered spam, but couldn't FF ship with an OGG codec for QT and DirectShow? It seems to me that that would serve to further facilitate users being able to use OGG in other places (in Safari, in their video players, editors, etc.). Then supporting the various backends would be an added bonus, the proprietary **** would come along for the ride. Would this somehow make OGG work worse than if it's built into FF directly instead of through the various OS backends?
Couldn't GStreamer be used on Mac OS X also, with a bridge to QuickTime to use additional codecs from there if needed? That way, Mozilla can ship a quality engine with "core" codecs that can be switched around as needed. Opera is including GStreamer with their Opera browser for their HTML5 implementation, though there are no plans to add a bridge to QuickTime, and they haven't gotten a working GStreamer build for Mac ready (the Songbird people have been using GStreamer on all platforms with Mozilla code, might want to look into them) http://my.opera.com/core/blog/2009/12/31/re-introducing-video
I'd love it if this was implemented, it would let me watch HTML5 video from sites like Youtube or Vimeo, since they use h264 which isn't likely to be implemented natively in Firefox...
Why not just defining an Plug-In API for <video> so that a third party can take over the job and implement H264 support given that Mozilla doesn't care.
Not planning on doing this now, so resolving WONTFIX.
This needs to be reopened. 799318 depends on it. https://bugzilla.mozilla.org/show_bug.cgi?id=799318
The APIs used by this patch are no longer available on current versions of OS X, so this approach and bug is dead.