Matthew Gregan [:kinetik] Reporter
	Description • 16 years ago

Bug 382267 covers the main work on the video element.  This bug is for the QuickTime backend implementation.

	Damon Sicore (:damons)
	Comment 1 • 16 years ago

marking wanted1.9.1? to get this in the triage queue.  If this needs to be blocking1.9.1?, please mark it as so.

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 2 • 16 years ago

Chris: What do you think about this one? Is this something we should do for 1.9.1?

	cajbir (:cajbir)
	Comment 3 • 16 years ago

Yes, the plan is for 1.9.1.

	Henrik Skupin [:whimboo][⌚️UTC+2]
	Comment 4 • 16 years ago

Chris, I imagine that the work which has to be done here applies to all OS?

	Henrik Skupin [:whimboo][⌚️UTC+2]
	Comment 5 • 16 years ago

After reading bug 435339 it looks like OS X only.

	cajbir (:cajbir)
	Comment 6 • 16 years ago

Yes, OS X only.

	Henrik Skupin [:whimboo][⌚️UTC+2]
	Comment 7 • 16 years ago

Clint, I believe this was a mistake on your side. Reverting flags.

	Håkan Waara
	Comment 8 • 16 years ago

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

	Matthew Gregan [:kinetik] Reporter
	Comment 9 • 16 years ago

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

	Tomas
	Comment 10 • 16 years ago

Any progres?

	Matthew Gregan [:kinetik] Reporter
	Comment 11 • 16 years ago

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

	Matthew Gregan [:kinetik] Reporter
	Comment 12 • 16 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

	Matthew Gregan [:kinetik] Reporter
	Comment 13 • 16 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.

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 14 • 16 years ago

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 ;)

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 15 • 16 years ago

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.)

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 16 • 16 years ago

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.

	JK
	Comment 17 • 15 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?

	Neal Gompa[:Conan Kudo]
	Comment 18 • 15 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)
http://my.opera.com/core/blog/2009/12/31/re-introducing-video

	Kuba Suder
	Comment 19 • 15 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...

	Lars Sonchocky-Helldorf
	Comment 20 • 15 years ago

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.

	Chris Pearce [:cpearce (Not reading bugmail)]
	Comment 21 • 14 years ago

Not planning on doing this now, so resolving WONTFIX.

	David Doukidis
	Comment 22 • 12 years ago

This needs to be reopened.

799318 depends on it.

https://bugzilla.mozilla.org/show_bug.cgi?id=799318

	Matthew Gregan [:kinetik] Reporter
	Comment 23 • 12 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.