So... Flash is going to support everything, which is great, but you still have the whacky situation of Firefox (without Flash) and Opera (ditto) supporting (what was On2?) vp8, which may be open, but is hardly a de facto standard.
mp4 (really H.264?, how can I keep track of the alphabet soup here?), is the de facto standard, because u-toob uses it (and more sites, like Vimeo, are adding it). Flash supports it and Quicktime supports it, which means that it will play pretty much everywhere: on the iDevices because they build in Quicktime (and Apple picks up the tab on the licensing fee, if any?), and everywhere else using Flash (and Adobe picks up the tab). So, I still recommend that Henry start by simply supporting/assuming mp4. We can worry about another format when there is one that actually has any market share. On 2011-01-05, at 11:23, Raju Bitter wrote: > Firefox 4.1 Beta already supports WebM video, as does Opera 10.6 and of > course Chrome 6+. > > Adobe Flash & WebM/VP8: http://blogs.adobe.com/flashplatform/?s=vp8 > >> Google Open Sources VP8 and Adobe Adds Flash Player Support > > Google announced that it would be open sourcing the VP8 video codec. At the >> same time we announced that we would support VP8 playback in Flash Player >> along with H.264 and VP6. For me the big takeaway from this is, Adobe has >> you covered no matter what format you choose. I’ll leave it to the browsers >> to battle on which one is best. We have no time frame for rolling VP8 >> support in Flash Player, but if you came by the Adobe sandbox you saw that >> we already have it working. > > > Would make it a logical decision to switch to WebM/VP8 for Flash playback > once Flash Players with VP8 support are available. > > On Wed, Jan 5, 2011 at 3:14 PM, P T Withington <[email protected]> wrote: > >> I wonder how u-toob handles this issue. Maybe right now the only non-flash >> browser is Safari? >> >> I really wonder if Mozilla is going to be able to maintain their stance. >> It's my understanding that u-toob encode their files as mp4 because both >> flash and QuickTime (safari) can play that. It seems unlikely that big video >> hosts are going to keep duplicate encodings of all their files around. >> >> On Jan 4, 2011, at 21:22, Henry Minsky <[email protected]> wrote: >> >> Firefox and Safari both support the <video> and <audio> HTML tags, but >> Safari only supports MPEG encoding, and Firefox only >> supports Theora (a royalty-free video encoding format). >> >> I've got a component for DHTML video playback, which looks like >> >> <html5videoview src="yourmovie.mp4"> >> >> But you don't want to hardcode the filename, because you need to choose at >> runtime which file to use for the browser. >> >> The browser kernel has to detect which browser is being used, and look up >> which encoding format(s) it supports. That code probably belongs in the >> browser kernel. >> >> And then maybe for a given "video" resource, we probably want some >> structured way to specify a list of different files/URLs and what their >> encoding is (encoding can be guessed from the file extension if we stick to >> some convention). There's suggested MIME types for mp4 and theora >> >> oga audio/ogg .ogv video/ogg >> >> .mp4 video/mp4 >> >> .mov video/quicktime >> >> .mp3 audio/mpeg >> >> I'm just not getting a clear idea of how this should be organized. Do we >> extend the <resource> tag to support specifying multiple encodings? >> >> You could have a list of files, CSS style, whose encodings is implicit: >> >> <resource name="myvideo" encodings="myvid.mp4;myvid.ogv> >> >> or fully specified >> >> <resource name="myvideo" >> encodings="myvid.mp4:video/mp4;myvid.ogv:video/ogg"> >> >> Then you could use that resource name in a video view, and it would do the >> browser dispatch for you >> >> <html5videoview resource="myvideo"> >> >> whereas if you want to force the URL you specify >> >> <html5videoview src="myvideo.mp4"> >> >> >> Thoughts? >> >> >> >> >> >> >> >> >> -- >> Henry Minsky >> Software Architect >> <[email protected]>[email protected] >> >> >>
