QuickTime backend for HTML5 video element




11 years ago
6 years ago


(Reporter: kinetik, Unassigned)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(1 attachment, 1 obsolete attachment)



11 years ago
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.
Flags: wanted1.9.1?
Priority: -- → P1
Chris: What do you think about this one? Is this something we should do for 1.9.1?

Comment 3

11 years ago
Yes, the plan is for 1.9.1.
Flags: wanted1.9.1? → wanted1.9.1+


11 years ago
Component: DOM: HTML → DOM: Core & HTML
Chris, I imagine that the work which has to be done here applies to all OS?
Component: DOM: Core & HTML → Video/Audio
QA Contact: general → video.audio
Hardware: Macintosh → All
Version: unspecified → Trunk
After reading bug 435339 it looks like OS X only.

Comment 6

11 years ago
Yes, OS X only.


11 years ago
Component: Video/Audio → DOM: Core & HTML
Hardware: All → Macintosh
Version: Trunk → unspecified
Clint, I believe this was a mistake on your side. Reverting flags.
Component: DOM: Core & HTML → Video/Audio
Hardware: Macintosh → All
Version: unspecified → Trunk

Comment 8

11 years ago
Is this ongoing work somewhere (on a hg branch?), or is it yet to begin?

Comment 9

11 years ago
There is ongoing work on a local git branch of Chris's video work.  I hope to post a patch pretty soon.

Comment 10

11 years ago
Any progres?

Comment 11

11 years ago
Posted patch wip patch (obsolete) — Splinter Review
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

Comment 12

11 years ago
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
Attachment #347003 - Attachment is obsolete: true

Comment 13

11 years ago
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.

Comment 17

10 years ago
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?

Comment 18

10 years ago
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)


10 years ago
Assignee: kinetik → nobody

Comment 19

10 years ago
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.
Closed: 9 years ago
Resolution: --- → WONTFIX

Comment 22

7 years ago
This needs to be reopened.

799318 depends on it.

Blocks: 799318

Comment 23

7 years ago
The APIs used by this patch are no longer available on current versions of OS X, so this approach and bug is dead.
No longer blocks: 799318
You need to log in before you can comment on or make changes to this bug.