Re: [whatwg] Some video questions
On Thu, May 15, 2008 at 12:43 AM, Ian Hickson [EMAIL PROTECTED] wrote: Here's a precise scenario: A user creates an HTML5 page, and of course uses the video element to embed their Windows Media content. They're rude, and could care less about Mac or Linux support. Will Safari provide an API that allows Microsoft to support this scenario [...] Yes, the Windows Safari browser would just use DirectShow to render the videos, and DirectShow allows Microsoft to register a new codec to handle the Windows Media content. FYI Safari on Windows uses Quicktime for video. Your answer yes is still correct, however. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Some video questions
Yes, the Windows Safari browser would just use DirectShow to render the videos, and DirectShow allows Microsoft to register a new codec to handle the Windows Media content. FYI Safari on Windows uses Quicktime for video. Your answer yes is still correct, however. The practical answer is “no”, since Microsoft will probably not be compelled to re-architect Silverlight as a collection QuickTime components for Apple desktop PCs. (Steve would never allow it on Apple mobile devices, of course.) Even the theoretical answer is probably “no”. Just as QuickTime needed a significant update to support frame reordering when Apple added AVC (H.264) support, it would likely need similar updates to support features and concepts unique to other media runtimes. IMHO, everybody will be happier focusing on what video does do, rather than being disappointed when “this could happen/that could happen” fantasies fail to materialize. From a cross-platform, cross-browser perspective —mobile too, remember — video is for “HTML 5 Video”, that being the freely implementable and royalty free combination of container and compressed video and audio formats that we all hope can be found. — Charles
Re: [whatwg] Some video questions
On Sun, 27 Jan 2008, Charles wrote: The video element supports width and height. Does this include the additional area needed (if necessary) by the controls? It strikes me that it shouldn't, since it would be odd for the video width and height to change when non-video decorators are shown/hidden. I don't see a standard controls height and width, which is fine, but will there be read-only attributes for the width, height and position for controls? The spec currently doesn't say. I've added an issue marker regarding this, but basically the rendering section will define this, based on implementation experience. On Mon, 28 Jan 2008, Charles wrote: If users do show the video element's controls, are the plug-in's native controls shown? No, the user agent is expected to provide its own controls, and not expose the embedding framework's controls. If that's the case, is the expectation that authors will need to temporarily hide controls (or make sure they're already hidden) before getting its height? The videoHeight attribute can be used to determine the actual native height of the video content. I have omitted a great deal of the remainder of this specification as it did not contain actionable feedback on the specification as far as I could tell. Please let me know if I missed something. On Tue, 29 Jan 2008, Charles wrote: For example: YouTube embeds SWF files. Shouldn't that be a video element from a semantic POV? If so, that seems to imply a requirement for the video element to be extendable with plug-ins. video would be appropriate for embedding the FLV files used by Flash players, but to embed the SWF files, the embed element is better suited. On Tue, 29 Jan 2008, Charles wrote: So, my questions remain. What I'm hearing is that (1) video will only be a cross-browser, cross-platform solution for exactly one format -- that freely implementable and royalty free combination of container and compressed video and audio formats -- and that (2) from a design perspective video transport controls may be any size (or no size at all if the browser vendor prefers overlays), requiring designers to roll their own if they need controls to be a predictable size. Correct, except that it's at least one format, not exactly one format. On Tue, 29 Jan 2008, Charles wrote: James wrote: Are you looking for a way for plugins, rather than the browser itself, to handle video? Yes, with the brower handling handles precendence and event routing, etc. Really not terribly different than plug-ins today, but semantically meaningful, straightforward, simple and consistent. I don't really understand what that would look like. It isn't what video is currently intended to be, though. On Tue, 29 Jan 2008, Charles wrote: Are Adobe/Microsoft going to be update their Flash/Silverlight browser plug-ins in order to be first-class video handlers in Safari on Mac and Windows? On Tue, 29 Jan 2008, Charles wrote: The question is not about what Adobe or Microsoft may or may not do. The question is about whether Safari (not to single out one browser) is going to (a) allow 3rd-party browser plug-ins to create support for more formats (b) using the video element (c) on the Safari platform. Yes, the WebKit implementation (Safari implementation) of video will allow people to provide new codecs to handle new formats. Here's a precise scenario: A user creates an HTML5 page, and of course uses the video element to embed their Windows Media content. They're rude, and could care less about Mac or Linux support. Will Safari provide an API that allows Microsoft to support this scenario [...] Yes, the Windows Safari browser would just use DirectShow to render the videos, and DirectShow allows Microsoft to register a new codec to handle the Windows Media content. On Thu, 31 Jan 2008, Christoph P�per wrote: Ian, |object| currently has special handling for images, shouldn't videos be dealt with similarily (i.e. not create a nested browsing context)? Since we're introducing video, I don't see much reason to go out of our way and support video in object as well. It would just make things even more complicated. Also |type=image| (or 'video') should be enough, without slash and subtype, but I've raised that before. I imagine I'll get to that feedback when I process the object element feedback then. :-) On Thu, 31 Jan 2008, Charles wrote: Imagine the QuickTime plug-in being able to register itself with IE's brower as a handler for video types that IE otherwise wouldn't handle. That seems like a very desirable thing, but the more we talk the more it seems outside the scope of what HTML5 can solve. The QuickTime framework can register itself as a codec in DirectShow, which would then work in IE. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A
Re: [whatwg] Some video questions
I replied as soon as I was able to review your example. You argued that a QuickTime movie can be used to make the host computer execute arbitrary algorithms and that rationalized your demand that the video element should support arbitrary virtual machines, including Adobe Flash. I would like to have a look at a convincing example supporting your argument; the one you provided is not satisfactory because it is a mere redirection. Yours sincerely Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Sent: Friday, May 02, 2008 7:18 PM To: 'WHAT working group' Subject: Re: [whatwg] Some video questions Not sure why you're responding to a 3-month-old email or what Turing complete has to do with anything (the QuickTime runtime is also Turing complete), but feel free to ping me off-list if you have questions. -- Charles -Original Message- From: Křištof Želechovski [mailto:[EMAIL PROTECTED] Sent: Friday, May 02, 2008 7:45 AM To: 'Charles'; 'WHAT working group' Subject: RE: [whatwg] Some video questions I am not sure what you had in mind. It seems irrelevant whether the video stream is embedded or linked from another location or using a different transport; it is still a video stream and the QuickTime player only displays it. On the other hand, Shockwave Flash is Turing-complete. That is a big difference. I am very disappointed. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Sent: Sunday, February 03, 2008 6:50 AM To: 'WHAT working group' Subject: Re: [whatwg] Some video questions Your movie showed as a grey square and hanged Internet Explorer and I had to log out. Was that intended? It's an ordinary QuickTime Movie and works fine. The content is irrelevant, but it shows that the files one will embed with video often won't actually contain any video media. This will be the case with every metafile format (.asx, .sdp, etc.), and nearly all modern container formats (.mov, .asf, .swf) that can reference media that lives elsewhere. -- Charles
Re: [whatwg] Some video questions
(This is only partially on-topic, so apologies in advance.) I would like to have a look at a convincing example supporting your argument... The best examples are no longer on the internet, since Apple long ago stopped advancing or evangelizing this capability of QuickTime. Two references I can point you do are Inside QuickTime: Interactive Movies[1], and the book Interactive QuickTime: Authoring Wired Media[2]. ...that rationalized your demand that the video element should support arbitrary virtual machines, including Adobe Flash. Any multimedia-centric runtime conceived or actively advanced during in the 1990s supports the kind of functionality you're talking about, which is why it doesn't make sense to put Flash into a different box. That's all kind of besides the main point, which is that it's a missed opportunity that video will only support one format across browsers/OSs. I'm okay with that, since this problem can be solved outside of HTML 5. -- Charles [1] http://developer.apple.com/documentation/QuickTime/IQ_InteractiveMovies/insi deqt_intmov.pdf [2] http://www.amazon.com/Interactive-QuickTime-Authoring-Wired-Developer/dp/155 8607463 -Original Message- From: Křištof Želechovski [mailto:[EMAIL PROTECTED] Sent: Saturday, May 03, 2008 4:59 AM To: 'Charles'; 'WHAT working group' Subject: RE: [whatwg] Some video questions I replied as soon as I was able to review your example. You argued that a QuickTime movie can be used to make the host computer execute arbitrary algorithms and that rationalized your demand that the video element should support arbitrary virtual machines, including Adobe Flash. I would like to have a look at a convincing example supporting your argument; the one you provided is not satisfactory because it is a mere redirection. Yours sincerely Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Sent: Friday, May 02, 2008 7:18 PM To: 'WHAT working group' Subject: Re: [whatwg] Some video questions Not sure why you're responding to a 3-month-old email or what Turing complete has to do with anything (the QuickTime runtime is also Turing complete), but feel free to ping me off-list if you have questions. -- Charles
Re: [whatwg] Some video questions
Not sure why you're responding to a 3-month-old email or what Turing complete has to do with anything (the QuickTime runtime is also Turing complete), but feel free to ping me off-list if you have questions. -- Charles -Original Message- From: Křištof Želechovski [mailto:[EMAIL PROTECTED] Sent: Friday, May 02, 2008 7:45 AM To: 'Charles'; 'WHAT working group' Subject: RE: [whatwg] Some video questions I am not sure what you had in mind. It seems irrelevant whether the video stream is embedded or linked from another location or using a different transport; it is still a video stream and the QuickTime player only displays it. On the other hand, Shockwave Flash is Turing-complete. That is a big difference. I am very disappointed. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Sent: Sunday, February 03, 2008 6:50 AM To: 'WHAT working group' Subject: Re: [whatwg] Some video questions Your movie showed as a grey square and hanged Internet Explorer and I had to log out. Was that intended? It's an ordinary QuickTime Movie and works fine. The content is irrelevant, but it shows that the files one will embed with video often won't actually contain any video media. This will be the case with every metafile format (.asx, .sdp, etc.), and nearly all modern container formats (.mov, .asf, .swf) that can reference media that lives elsewhere. -- Charles
Re: [whatwg] Some video questions
Martin, I'll be satisfied if someone tells me that video is not intended to be the preferred way to embed video on web pages, in which case I'll quietly return to my corner. I may be misinterpreting your tone, but from reading this discussion it seems that you're deliberately being difficult. You're quoting a two-month old email on a topic I'd resigned myself to, and I'm a bit reluctant to respond because any discussion about it seems to be perceived as difficult. That said... The Quicktime browser plugin is a video player. Great, this helps me understand your terminology. In my world the (for example) QuickTime plug-in is more just a shim, since the plug-in isn't playing the media but is instead instantiating QuickTime (the API) to play the media. I think we'd be in general agreement if we spent a few minute trading terminology. The HTML5 spec should ultimately require at least one video format that will be available in all compliant implementations. I understand, assuming that by video format you include an associated audio bitstream format and container format. It might be clearer for us to say linear media format. It's a nonsense to suggest that video could be player-agnostic, because video *is* a player. In my world, video is just an HTML element. It's by definition player-agnostic in the sense browsers will use different players (depending on what's available on the host OS) to play the media associated with a particular video element. And just to repeat the facts as I understand them: - video will universally support a base video/audio format (linear media format) defined by the final HTML 5 specification, assuming a suitable combination of container and bitstream formats can be found. - video will not universally support any other format. Is that correct? Thanks, -- Charles
Re: [whatwg] Some video questions
On 07/04/2008, Charles [EMAIL PROTECTED] wrote: And just to repeat the facts as I understand them: - video will universally support a base video/audio format (linear media format) defined by the final HTML 5 specification, assuming a suitable combination of container and bitstream formats can be found. - video will not universally support any other format. Is that correct? As I understand it. Perhaps if someone writes a codec for H.120 ... - d.
Re: [whatwg] Some video questions
Charles wrote: Maciej, But I think the premise of the question misses the point of the video element. I may very well be completely missing the point. I'll be satisfied if someone tells me that video is not intended to be the preferred way to embed video on web pages, in which case I'll quietly return to my corner. I may be misinterpreting your tone, but from reading this discussion it seems that you're deliberately being difficult. Of course video is the preferred way to embed video on web pages in HTML5. It seems that you are either inadvertently or deliberately misunderstanding the stack of components that implement audio and video playback in browsers. * The Quicktime browser plugin is a video player. * The Windows Media browser plugin is a video player. * The Totem Movie Player browser plugin is a video player. * YouTube's /player2.swf is a video player. * The video player used on channel9.msdn.com is a video player. * A browser's implementation of video is a video player. None of the above things are videos. They are used to play videos. None of the above things are media frameworks, either: * Quicktime's browser plugin is a front-end for the Quicktime media framework. * Windows Media browser plugin is a front-end for Microsoft's DirectShow media framework. * Totem Movie Player plugin is a front-end for either gstreamer or xine, which are both media frameworks. * YouTube's player is a front-end implemented in Flash to the media framework built in to the flash plugin. * The video player used on channel9.msdn.com is a front-end implemented in Silverlight to Silverlight's video API. (which I suspect uses DirectShow when running on on Windows.) * video is a front-end to a media framework or some media frameworks of the browser implementor's choice. It is up to the page author to decide which video player they wish to use. Currently, many authors create their own players in Flash or they use someone else's player written in Flash. video is an alternative to a video player implemented in Flash, and an alternative to embedding the Windows Media browser plugin. It is designed to embed video, not video players implemented in other technologies. But in Safari, video = QuickTime. Is that not a player-centric rather than a content-centric design? Please be careful to qualify QuickTime when you refer to it. It's perhaps partially Apple's fault for calling everything by the same name, but it's important to keep in mind the difference between: * The QuickTime player, which is an application users can run. * The QuickTime browser plugin, which is a browser plugin similar to the QuickTime player. * The QuickTime framework, which is an API provided by MacOS for video playback, which is used by QuickTime player and is also used by iTunes, Safari, and I imagine many other MacOS applications. (I'm not a Mac user, so I hope you'll excuse the lack of an extensive list of examples.) The same distinction exists in Windows. Windows Media Player, WinAmp, Media Player Classic and several other applications are all front-ends to DirectShow, which is the Windows equivalent of the QuickTime framework. Likewise, there are several Gtk+ and GNOME applications that use gstreamer. Neither QuickTime the framework, DirectShow nor gstreamer are video players. They are frameworks on which players are built. One thing that QuickTime the framework, DirectShow and gstreamer all have in common is that all of the media decoding is done via pluggable modules, so any of these frameworks can, assuming a suitable module is installed, play any video format. (assuming that we define video to mean a non-interactive sequence of images optionally synchronised with some audio.) The HTML5 spec doesn't say you must implement video with Quicktime, it simply describes the behavior of a video element and how it interacts with the page it's embedded in. It's up to the browser vendor to decide how best to achieve the behavior that the specification requires. I believe that it is correct to say that in the version of Safari under discussion, the video element is implemented using the QuickTime framework. However, you don't need to care about this. All you need to care about is what video codecs it supports. The HTML5 spec should ultimately require at least one video format that will be available in all compliant implementations, which Apple is likely to implement by simply supplying a Quicktime module that can decode that format. It is an accepted open issue with the HTML5 spec that there is not currently at least one standard video format required. You remarked in an earlier thread that you think YouTube ought to be able to embed their player via video. Here lies the confusion: video doesn't embed players, it embeds video. What we want isn't this:[1] video src=/player2.swf but rather something like: video src=/videos/Z73xtJN6IdA.flv That is, they would
Re: [whatwg] Some video questions
I installed the latest Quick Time player and I still cannot see how it works fine. The browser shows the Quick Time logo with a running shuttle underneath. The browser is Ready and the player is Negotiating. The movie seems invalid to me. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Sent: Sunday, February 03, 2008 6:50 AM To: 'WHAT working group' Subject: Re: [whatwg] Some video questions Your movie showed as a grey square and hanged Internet Explorer and I had to log out. Was that intended? It's an ordinary QuickTime Movie and works fine. The content is irrelevant, but it shows that the files one will embed with video often won't actually contain any video media. This will be the case with every metafile format (.asx, .sdp, etc.), and nearly all modern container formats (.mov, .asf, .swf) that can reference media that lives elsewhere. -- Charles
Re: [whatwg] Some video questions
Chris, The movie seems invalid to me. The Movie is fine. If your QuickTime streaming preferences is set to automatic, then the problem is most likely a network configuration issue with your firewall and/or your router. Please don't post QuickTime technical support questions to this list. If you email me privately (charles at my domain), I'll do everything I can to help. I'm travelling, so replies may take up to a day. Thanks, -- Charles -Original Message- From: Kristof Zelechovski [mailto:[EMAIL PROTECTED] Sent: Sunday, February 03, 2008 1:10 AM To: 'Charles'; 'WHAT working group' Subject: RE: [whatwg] Some video questions I installed the latest Quick Time player and I still cannot see how it works fine. The browser shows the Quick Time logo with a running shuttle underneath. The browser is Ready and the player is Negotiating. The movie seems invalid to me. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Sent: Sunday, February 03, 2008 6:50 AM To: 'WHAT working group' Subject: Re: [whatwg] Some video questions Your movie showed as a grey square and hanged Internet Explorer and I had to log out. Was that intended? It's an ordinary QuickTime Movie and works fine. The content is irrelevant, but it shows that the files one will embed with video often won't actually contain any video media. This will be the case with every metafile format (.asx, .sdp, etc.), and nearly all modern container formats (.mov, .asf, .swf) that can reference media that lives elsewhere. -- Charles
Re: [whatwg] Some video questions
Your movie showed as a grey square and hanged Internet Explorer and I had to log out. Was that intended? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Sent: Friday, February 01, 2008 12:02 AM To: 'WHAT working group' Subject: Re: [whatwg] Some video questions Inserting a [SWF] file into a video element is similar to inserting an HTML file that happens to have a link to video: sure, it links to a video, but it does a billion other things too - it isn't in itself the video. I hear you. FWIW, here's a QuickTime Movie that's also not in itself the video: http://wiltgen.net/tempy/badder.mov Please pardon the content. It's what I had handy from some previous testing. :^)
Re: [whatwg] Some video questions
Your movie showed as a grey square and hanged Internet Explorer and I had to log out. Was that intended? It's an ordinary QuickTime Movie and works fine. The content is irrelevant, but it shows that the files one will embed with video often won't actually contain any video media. This will be the case with every metafile format (.asx, .sdp, etc.), and nearly all modern container formats (.mov, .asf, .swf) that can reference media that lives elsewhere. -- Charles
Re: [whatwg] Some video questions
On Jan 31, 2008, at 03:01, Charles wrote: Semantically, you don't want web video (regardless of format) to be marked up as video? What would be the benefit of instantiating the Flash Player with video? Wouldn't it just be less compatible than object/embed? (Also, since video isn't a video player player, I think instantiating Flash Player with it wouldn't even be semantically pure.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Some video questions
Charles: I was hoping that video would make Objecty http://wiltgen.net/ objecty/ redundant by making it easy for authors to embed video in a very simple, normalized fashion across formats, browsers and OSs. The |video| element in HTML5 will make it easy to embed videos (potentially including those contained in FLV). The |embed| element in HTML5 makes it easy to embed Flash applets etc. video src=foo.flv width=480 height=200 poster=300- poster.jpg/video embed src=player.swf?file=foo width=480 height=226/embed Your |class|-hooked script Objecty seems to try to support both and also supports certain page URLs (You Tube, Google Video). The |object| element in HTML5 could still be used like that, but you would probably choose the more fitting of the other two elements (at least as soon as |video| is widely supported, while |embed| already is). Ian, |object| currently has special handling for images, shouldn't videos be dealt with similarily (i.e. not create a nested browsing context)? Also |type=image| (or 'video') should be enough, without slash and subtype, but I've raised that before. Now I understand that video will be considered successful without having fixed video embeddeding in general, which is fine. Your loose use of terminology and snappy tone are seriously not helping.
Re: [whatwg] Some video questions
[Charles] Now I understand that video will be considered successful without having fixed video embeddeding in general, which is fine. [Christopher] Your loose use of terminology and snappy tone are seriously not helping. If what you quoted above is an example of my tone, then you're misinterpreting it. I really am fine if video is widely deployed as currently designed. My opinion is that it will not widely adopted if it can't be used for mainstream scenarios, and that this is probably the best time to speak up. My terminology may seem loose if you look at the video on a typical YouTube page and think applet. For content creators and viewers, YouTube is video. Nobody calls their friends to ask them to play a YouTube applet. :^) If the interactivity is the disconnect for you, it's worth noting that mainstream media runtimes have been able to mix interactive elements with video/audio for a decade or more. Video with interactivity isn't an applet any more than video with captions is text. If it's that the SWF references a FLV, QuickTime Movies have been able to reference media pretty much forever, and when you embed an ASX with references with Windows Media content, you're still embedding video even though the metafile happens to be a text file. If the goal isn't that most video content on the web should be semantically tagged as video, then my agruments are moot. If the goal isn't that video from YouTube and other social video sites should be able to be shared using video elements, then my agruments are moot. Hopefully that clarifies things for you. -- Charles
Re: [whatwg] Some video questions
On 31 Jan 2008, at 17:50, Charles wrote: If it's that the SWF references a FLV, QuickTime Movies have been able to reference media pretty much forever, and when you embed an ASX with references with Windows Media content, you're still embedding video even though the metafile happens to be a text file. Whereas it is possible to get the video from a QuickTime container, it is not possible to get a FLV from a SWF, making it impossible to directly control the video. The video element exists to contain container formats (of which Flash is not one, though FLV is), and nothing else. Inserting a Flash file into a video element is similar to inserting an HTML file that happens to have a link to video: sure, it links to a video, but it does a billion other things too — it isn't in itself the video. -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] Some video questions
Inserting a [SWF] file into a video element is similar to inserting an HTML file that happens to have a link to video: sure, it links to a video, but it does a billion other things too - it isn't in itself the video. I hear you. FWIW, here's a QuickTime Movie that's also not in itself the video: http://wiltgen.net/tempy/badder.mov Please pardon the content. It's what I had handy from some previous testing. :^) Sementically that Movie *is* video (even though technially it contains no media), and so it seems desirable to want to embed it using video. And we'll be able to in Safari, but not IE. Or at least, I'm pretty confident that Apple won't be packaging QuickTime as DirectShow filters. Imagine the QuickTime plug-in being able to register itself with IE's brower as a handler for video types that IE otherwise wouldn't handle. That seems like a very desirable thing, but the more we talk the more it seems outside the scope of what HTML5 can solve. ...it is not possible to get a FLV from a SWF, making it impossible to directly control the video. It is possible to get the FLV from a SWF, but I think you're saying that you think that SWF is inappropriate for video because there's no way to (for example) random access through the video from an external control? -- Charles
Re: [whatwg] Some video questions
On Jan 31, 2008, at 3:01 PM, Charles wrote: Inserting a [SWF] file into a video element is similar to inserting an HTML file that happens to have a link to video: sure, it links to a video, but it does a billion other things too - it isn't in itself the video. I hear you. FWIW, here's a QuickTime Movie that's also not in itself the video: http://wiltgen.net/tempy/badder.mov Please pardon the content. It's what I had handy from some previous testing. :^) Sementically that Movie *is* video (even though technially it contains no media), and so it seems desirable to want to embed it using video. And we'll be able to in Safari, but not IE. Or at least, I'm pretty confident that Apple won't be packaging QuickTime as DirectShow filters. Imagine the QuickTime plug-in being able to register itself with IE's brower as a handler for video types that IE otherwise wouldn't handle. That seems like a very desirable thing, but the more we talk the more it seems outside the scope of what HTML5 can solve. If IE implemented video based on DirectShow, then it seems there would already be a way for Apple to do that (write a DirectShow filter). I can't promise either way that Apple would or wouldn't provide extended video codecs to IE's video, but I don't think the decision will depend deeply on whether the relevant API is ActiveX or DirectShow or something else. Regards, Maciej
Re: [whatwg] Some video questions
On Tue, 29 Jan 2008 20:57:35 -0500, Charles [EMAIL PROTECTED] wrote: Here's a precise scenario: A user creates an HTML5 page, and of course uses the video element to embed their Windows Media content. They're rude, and could care less about Mac or Linux support. Will Safari provide an API that allows Microsoft to support this scenario by enhancing their Silverlight plug-in? Microsoft provides a QuickTime component for Windows Media; would that not be sufficient? http://www.microsoft.com/windows/windowsmedia/player/wmcomponents.mspx I don't understand why you're complicating things by talking about Silverlight, here. -- J. King http://jking.dark-phantasy.com/
Re: [whatwg] Some video questions
Thanks for the conversation, folks! I was hoping that video would make Objecty http://wiltgen.net/objecty/ redundant by making it easy for authors to embed video in a very simple, normalized fashion across formats, browsers and OSs. Now I understand that video will be considered successful without having fixed video embeddeding in general, which is fine. Microsoft provides a QuickTime component for Windows Media; would that not be sufficient? Unfortunately not. There's the installed base problem we've talked about a lot in the thread, plus Flip4Mac WM doesn't support all Windows Media features. Really, it was always just a stop-gap until Silverlight. -- Charles
Re: [whatwg] Some video questions
On 30/01/2008, at 12:54 PM, Charles wrote: Thanks for the conversation, folks! I was hoping that video would make Objecty http://wiltgen.net/ objecty/ redundant by making it easy for authors to embed video in a very simple, normalized fashion across formats, browsers and OSs. Now I understand that video will be considered successful without having fixed video embeddeding in general, which is fine. What part of video does it not fix? It defines a standard API for all implementers, with standard html-native markup. Afaict you just want to be able to replace your use of object with video which is entirely pointless, the purpose of the video tag is to provide a standardised native html element, not another plugin mechanism to replace object -- by definition a plugin is both non- native and non-standard so has no relevance here. Once the spec is complete you'll be able to use standard html to say here is a video, then use JS to bind custom controls (if you so desire), and everything will be wholesome and good. If you want to use a plugin use object that's what object is for. --Oliver Microsoft provides a QuickTime component for Windows Media; would that not be sufficient? Unfortunately not. There's the installed base problem we've talked about a lot in the thread, plus Flip4Mac WM doesn't support all Windows Media features. Really, it was always just a stop-gap until Silverlight. -- Charles
Re: [whatwg] Some video questions
What part of video does it not fix? It fixes the problem for formats supported by the player(s) that a particular browser vendor thinks is important. That's good as far as it goes, don't get me wrong. I understand Apple's POV is that cascading source elements makes the debate moot. Unfortunately, content providers usually can't provide the same content in different formats -- either it's too expensive to re-author a similar experience for multiple formats, or functionality they need isn't available in multiple formats, or it's too costly to create server farms for multiple formats, etc. History shows us that even when they can, they don't. Afaict you just want to be able to replace your use of object with video which is entirely pointless... Semantically, you don't want web video (regardless of format) to be marked up as video? Once the spec is complete you'll be able to use standard html to say here is a video, then use JS to bind custom controls (if you so desire), and everything will be wholesome and good. Again, that's great for what it is. -- Charles
Re: [whatwg] Some video questions
Charles wrote: Unfortunately, content providers usually can't provide the same content in different formats -- either it's too expensive to re-author a similar experience for multiple formats, or functionality they need isn't available in multiple formats, Transcoding video really isn't hard thesedays -- e.g. you can download VLC and set a job going within minutes. or it's too costly to create server farms for multiple formats, etc. History shows us that even when they can, they don't. This, however, is a fair point. Andrew Sidwell
Re: [whatwg] Some video questions
On 28 Jan 2008, at 23:32, Charles wrote: The video element offers an interface to the native media playback capabilities of the platform. The browser platform (e.g. WebKit), the multimedia platform (e.g. QuickTime) or the OS platform (e.g. Mac OS X)? Whatever the browser chooses to use. In WebKit's case, this is the OS (so QT on OS X, DirectShow on Windows, and GStreamer on GTK). Presto (in Opera) provides its own decoder (for Ogg/Vorbis/Theora, likewise does Gecko. It is not a plug-in mechanism and it is not suitable for embedding things like Flash or Silverlight. So for Safari on both Macintosh and Windows, is Apple's intent that video will only work for formats supported by QuickTime? Apple's intent, as far as I'm aware, is to use the natively supported multimedia support of a given environment (as WebKit isn't for multimedia). Also, as Henri has already said, QuickTime supports plugins itself. And given that little internet content targets QuickTime, who exactly will be using the video tag? There is a _huge_ amount of content on the web that uses MPEG-4, which QuickTime supports (note that on Windows DirectShow doesn't support MPEG-4 out of the box, and AFAIK only supports MPEG-1 and WMV (for video)). There's also still a large amount of content that relies on the QuickTime container format (.mov), even if the content is MPEG-4 (whose own container is based on the QT one). -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] Some video questions
So for Safari on both Macintosh and Windows, is Apple's intent that video will only work for formats supported by QuickTime? And given that little internet content targets QuickTime, who exactly will be using the video tag? Even though video codecs aren't pluggable on the browser level in Safari, they are pluggable on the QuickTime level. Point well taken...in theory, formats could create Mac/Windows import components, media handlers, movie controllers, etc. to plug their format into QuickTime. In practice, users aren't aware of that QuickTime can be extended like this, and the very few that are use them primarily to view and convert files in format X (vs. as a way to deploy contnt in format X). The video element would solve a real problem if it worked with plug-ins. If that's not the requirement, I don't currently understand who would use it or how it could become mainstream. For example: YouTube embeds SWF files. Shouldn't that be a video element from a semantic POV? If so, that seems to imply a requirement for the video element to be extendable with plug-ins. -- Charles
Re: [whatwg] Some video questions
Oliver, You're basically complaining about the codec choice... No, this thread isn't about that. I'm saying that the video element doesn't solve the problem that needs solving. Read the thread again, ignore the stuff about 3rd-party QuickTime components, and hopefully my points will be clear. -- Charles
Re: [whatwg] Some video questions
Also, as Henri has already said, QuickTime supports plugins itself. Right, but not more than 0% (rounded) of users know about or install these. This is why it's difficult to see the relevance. There is a _huge_ amount of content on the web that uses MPEG-4... There's some MPEG-4 content available on the internet, but it's primarily restricted to video podcasts designed for iPods, and then is generally only available in feeds. When that same content is made available on the web, it's generally encoded as Flash. Most MPEG-4 content available on the web per se is generally designed for mobile (i.e. m.youtube.com). deep breath I think my point's getting lost. I'm a huge fan of MPEG-4, and am glad I was around as Apple's QuickTime Evangelist during its birth. The problem is that the video element doesn't appear solve the problem of how to embed content in a player-agnostic fashion. It should unify video embedding, but as designed, it doesn't. -- Charles
Re: [whatwg] Some video questions
On Jan 29, 2008, at 11:30 AM, Charles wrote: Also, as Henri has already said, QuickTime supports plugins itself. Right, but not more than 0% (rounded) of users know about or install these. This is why it's difficult to see the relevance. Actually, many QuickTime codec plugins are quite popular, including the Flip4Mac codec for Windows Media, the DivX codec, and to a lesser extent the Ogg codec. Enough that we get Safari bug reports when these extensions don't work or cause problems. Extending QuickTime is these days a more popular way to provide support for specific video formats on the Mac than writing a browser plugin. There is a _huge_ amount of content on the web that uses MPEG-4... There's some MPEG-4 content available on the internet, but it's primarily restricted to video podcasts designed for iPods, and then is generally only available in feeds. Here's some interesting MPEG content served without flash wrappers: http://www.apple.com/trailers/ . When that same content is made available on the web, it's generally encoded as Flash. Most MPEG-4 content available on the web per se is generally designed for mobile (i.e. m.youtube.com). Flash isn't a video codec, there's no such thing as encoding video as Flash. What people actually do is embed a video *player* that's implemented in Flash, and which loads video content in a format Flash can handle. Older versions of Flash used a proprietary codec for this but newer versions of Flash support H.264/MPEG-4. Thus, it's likely that a lot of web video content will be playable in QuickTime without its Flash wrapper. Whether anyone will choose to do this is an open question. deep breath I think my point's getting lost. I'm a huge fan of MPEG-4, and am glad I was around as Apple's QuickTime Evangelist during its birth. The problem is that the video element doesn't appear solve the problem of how to embed content in a player-agnostic fashion. It should unify video embedding, but as designed, it doesn't. Flash is not a video format. It's more of an applet format like Java that supports general programming of interactive content. You can use it to play video, but that doesn't make it a video format any more than Java is. It's true that using Flash to play video is very popular on the web these days. That is part of why we want to create a viable alternative that doesn't rely on proprietary single-vendor technologies. Regards, Maciej
Re: [whatwg] Some video questions
Maciej, Actually, many QuickTime codec plugins are quite popular... I guess popular is relative. The installed base of the most popular set of 3rd-party QuickTime components (Flip4Mac WM) is miniscule compared to Linux installed base, and is closer to 5,000 than 50,000. Flash isn't a video codec, there's no such thing as encoding video as Flash. I'll gladly rephrase as using compressed media formats supported by the version of Flash one is targeting, to a container format supported by the version of Flash one is targeting, intended for playback using the targeted version of the Flash runtime if that helps. Flash is not a video format. Thanks, I have a good understanding of what Flash is. :^) Here's some interesting MPEG content served without flash wrappers: http://www.apple.com/trailers/ No, those are QuickTime Movies that happen to use MPEG-4 codecs. They're not MPEG-4 files. So, my questions remain. What I'm hearing is that (1) video will only be a cross-browser, cross-platform solution for exactly one format -- that freely implementable and royalty free combination of container and compressed video and audio formats -- and that (2) from a design perspective video transport controls may be any size (or no size at all if the browser vendor prefers overlays), requiring designers to roll their own if they need controls to be a predictable size. Am I crazy, or is there an opportunity to fix this before video joins blink? :O) --- Charles
Re: [whatwg] Some video questions
Am I crazy, or is there an opportunity to fix this before video joins blink? :O) You're basically complaining about the codec choice -- but as has been said before, the choice of codec has not yet been made, and there are numerous complex factors involved in making that that decision -- it's not a trivial matter of making the spec say use codec x. You should really read the mailing list archives, as they contain numerous discussions on this topic. --Oliver --- Charles
Re: [whatwg] Some video questions
Charles wrote: Oliver, You're basically complaining about the codec choice... No, this thread isn't about that. I'm saying that the video element doesn't solve the problem that needs solving. Read the thread again, ignore the stuff about 3rd-party QuickTime components, and hopefully my points will be clear. Can you explain it again, because I'm not sure I fully understand what you're trying to say and I don't seem to be the only one. AIUI, the current situation with video is: We are looking for a single format that all parties will be willing and able to deploy. If found, this format will be a MUST support for UAs, so providing authors with a single target codec Independent of that, the video element allows authors to target multiple codecs and then allows the browser to select one that it supports. A strict reading of the spec suggests that UAs are not allowed to allocate any space in the content for controls; they must overlay or be part of the browser chrome. I don't know if this is a correct reading of the spec, or if there is any harn in allowing the UA to take up some of the allocated space with controls. What else do you want?
Re: [whatwg] Some video questions
Your original question (about control sizes, etc) was answered very quickly -- the video element provides a block that displays video, other css elements can be used to provide the controls -- there is no requirement for the actual controls to be visually attached to the video element itself, so making the control dimensions be implicit in the video element is either restrictive (the controls must be visually connected to the video in a predefined way) or redundant (you have two mechanisms to define controls, either as generic css or using a restricted amount of control inside the visual area of the video element). Subsequently you turned it into the well covered topic of codecs -- i had merely assumed that as your original question had been answered you were asking a separate question on the topic of codec selection, which as i said has already been covered in detail and is non-trivial. --Oliver On 29/01/2008, at 2:00 PM, Charles wrote: Oliver, You're basically complaining about the codec choice... No, this thread isn't about that. I'm saying that the video element doesn't solve the problem that needs solving. Read the thread again, ignore the stuff about 3rd-party QuickTime components, and hopefully my points will be clear. -- Charles
Re: [whatwg] Some video questions
[Oliver] Subsequently you turned it into the well covered topic of codecs... The question was: As designed, is video a cross-browser, cross-platform solution for exactly one format, which is whatever is decided on as the freely-implementable and royalty free combination of container and compressed video and audio formats? Note that I'm not asking what those container and compressed media formats might be. I'm just trying to understand the scope of the problem that video is supposed to solve. [James] Can you explain it again, because I'm not sure I fully understand what you're trying to say and I don't seem to be the only one. The video element doesn't appear solve the problem of how to embed video content in a player- and browser- agnostic fashion. HTML 5 provides an opportunity to normalize how video embedding is done for most scenarios, making it as easy to embed video as it is an image. But as designed, video appears to only address an as-yet-undiscovered combination of container and media formats. This seems like a missed opportunity at best. Technically, it doesn't seem like it'd be difficult to allow various media runtimes to register as first-class video clients. -- Charles
Re: [whatwg] Some video questions
At 14:47 -0800 29/01/08, Charles wrote: [Oliver] Subsequently you turned it into the well covered topic of codecs... The question was: As designed, is video a cross-browser, cross-platform solution for exactly one format, which is whatever is decided on as the freely-implementable and royalty free combination of container and compressed video and audio formats? Note that I'm not asking what those container and compressed media formats might be. I'm just trying to understand the scope of the problem that video is supposed to solve. Video is intended, I think to cover a) any mandated format that we settle on b) any recommended or vendor-selected formats that the vendors choose to support. This is in a context of a cascading series of source elements that can indicate, in preference order, which encodings the author is providing. Charles, you know we're working on (a); at the moment, we're covering (b) since (a) isn't yet settled. But in the meantime there's lots of work also to be done on the question of what attributes, events, and DOM interface (for example) are right for this element, unifying that behavior. The webkit support is intended to allow you to explore those, and other, aspects of integration (e.g. sizing integrated into the browser also). Note that webkit is open-source, which I assume means you could apply such changes to your version as you consider to be improvements. Exactly what extensibility should be and will be provided under various implementations of video in various browsers, and at what level (e.g. at the browser, framework, or codec level) remains to be seen, of course. In the meantime, please see what the support does and what it teaches us; it's important to get usage experience. -- David Singer Apple/QuickTime
Re: [whatwg] Some video questions
Charles wrote: [James] Can you explain it again, because I'm not sure I fully understand what you're trying to say and I don't seem to be the only one. The video element doesn't appear solve the problem of how to embed video content in a player- and browser- agnostic fashion. HTML 5 provides an opportunity to normalize how video embedding is done for most scenarios, making it as easy to embed video as it is an image. But as designed, video appears to only address an as-yet-undiscovered combination of container and media formats. This seems like a missed opportunity at best. Technically, it doesn't seem like it'd be difficult to allow various media runtimes to register as first-class video clients I'm not sure exactly what you want the spec to say here (perhaps because I'm no clear what a media runtime is - is a codec a media runtime? Is Flash? Is a Java applet? Is the mplayer plugin?). Since browsers are free to implement native video support with a pluggable backend (which, indeed, WebKit is doing by leveraging Quicktime and which Opera and Mozilla could in principle do by using e.g. gStreamer), registering different codecs to provide first-class video clients is already possible. A good implementation would prompt for codec download when no suitable installed codecs were found. However I get the impression that this is not what you are after. Are you looking for a way for plugins, rather than the browser itself, to handle video? If so, why? It seems to me that plugins are limited in scope and provide a poor user experience compared to native support and it's not clear what advantages they would have.
Re: [whatwg] Some video questions
The video element doesn't appear solve the problem of how to embed video content in a player- and browser- agnostic fashion. HTML 5 provides an opportunity to normalize how video embedding is done for most scenarios, making it as easy to embed video as it is an image. But as designed, video appears to only address an as-yet-undiscovered combination of container and media formats. This seems like a missed opportunity at best. Technically, it doesn't seem like it'd be difficult to allow various media runtimes to register as first-class video clients. The purpose of the video element is to provide native support for video content and remove the need for external proprietary plugins, not to provide object mk 2. The video element is much more flexible in that it allows all controls, etc to be defined using full css, rather than requiring the controls to be embedded in the plugin view. Your assertion that video does not provide a browser agnostic mechanism for providing video content appears to be driven by the idea that html5 is finalised -- it's not, we have yet to make any decision on exactly which codecs and transport formats will be expected. Finally, the method through which content is decoded (once you know the codec) in the browser is an implementation detail -- WebKit uses QuickTime, WebKit/ Gtk uses gstreamer, Firefox and Opera use builtin codecs (afaik) -- so it is not the place of the html5 spec to define it. --Oliver -- Charles
Re: [whatwg] Some video questions
At 16:06 -0800 29/01/08, Charles wrote: James, Since browsers are free to implement native video support with a pluggable backend... I understand, but something makes me think that this problem won't get solved when developers are just free to solve it. (This isn't a criticism of browser developers, BTW. There's no incentive to fix anything but the formats they care about.) Just to focus on one popular way of putting video on the web, Apple won't be supporting Flash video* and Adobe won't again package Flash as a QuickTime media type. Are you looking for a way for plugins, rather than the browser itself, to handle video? Yes, with the brower handling handles precendence and event routing, etc. But that's roughly what the cascading source elements do. say you have 85% of your hits from two browser vendors, A and B, each of whom has a specific optional format they support that you think is better than the mandated one. You write video... source vendorA... source vendorB... source mandatedDefault... /video and the rest of your page gets a uniform interface no matter what browser is in effect. Indeed, if you later decide to support vendorC's format, you can insert that without changing anything else -- the rest of the HTML, the scripts, event handling, nothing. Seems like a big advantage to me. And if the mandated format is good enough, you have (we intend) 100% coverage from that, also. You get real integration with the rest of HTML and CSS etc. These all seem like pretty strong advantages to me. And, in addition, nothing stops a vendor from having plug-ins at the browser, framework, or codec level, to offer further flexibility. What am I missing that you don't like? -- David Singer Apple/QuickTime
Re: [whatwg] Some video questions
James, Since browsers are free to implement native video support with a pluggable backend... I understand, but something makes me think that this problem won't get solved when developers are just free to solve it. (This isn't a criticism of browser developers, BTW. There's no incentive to fix anything but the formats they care about.) Just to focus on one popular way of putting video on the web, Apple won't be supporting Flash video* and Adobe won't again package Flash as a QuickTime media type. Are you looking for a way for plugins, rather than the browser itself, to handle video? Yes, with the brower handling handles precendence and event routing, etc. Really not terribly different than plug-ins today, but semantically meaningful, straightforward, simple and consistent. -- Charles *Yes, I know Apple hasn't committed to /not/ supporting Flash...
Re: [whatwg] Some video questions
Dave, What am I missing that you don't like? Are Adobe/Microsoft going to be update their Flash/Silverlight browser plug-ins in order to be first-class video handlers in Safari on Mac and Windows? From what I'm hearing, the answer is no. -- Charles P.S. I understand QuickTime components would be a Safari-only solution, but that's a non-starter on Windows and is very unlikely on Mac OS. P.P.S. I understand that the the world can ignore video and continue to embed as they currently do.
Re: [whatwg] Some video questions
On Jan 29, 2008, at 5:11 PM, Charles wrote: Are Adobe/Microsoft going to be update their Flash/Silverlight browser plug-ins in order to be first-class video handlers Why would they? Those aren't video plug-ins. They're general purpose applet plug-ins. -- Darin
Re: [whatwg] Some video questions
At 17:11 -0800 29/01/08, Charles wrote: Dave, What am I missing that you don't like? Are Adobe/Microsoft going to be update their Flash/Silverlight browser plug-ins in order to be first-class video handlers in Safari on Mac and Windows? Why ask me what other vendors will do with their proprietary formats (or their browser, in the case of Microsoft)? P.P.S. I understand that the the world can ignore video and continue to embed as they currently do. And for some solution vendors, embed/object may be a preferred direction, and for some content owners, they may prefer to continue to use systems that use embed/object and require optional downloads for their clients, with the consequent uncertainty of support. I hope that there are few in both categories, but I expect it will remain a viable option. -- David Singer Apple/QuickTime
Re: [whatwg] Some video questions
Dave, Are Adobe/Microsoft going to be update their Flash/Silverlight browser plug-ins in order to be first-class video handlers in Safari on Mac and Windows? Why ask me what other vendors will do with their proprietary formats (or their browser, in the case of Microsoft)? slapping forehead I'll try again. :^) The question is not about what Adobe or Microsoft may or may not do. The question is about whether Safari (not to single out one browser) is going to (a) allow 3rd-party browser plug-ins to create support for more formats (b) using the video element (c) on the Safari platform. Here's a precise scenario: A user creates an HTML5 page, and of course uses the video element to embed their Windows Media content. They're rude, and could care less about Mac or Linux support. Will Safari provide an API that allows Microsoft to support this scenario by enhancing their Silverlight plug-in? -- Charles
Re: [whatwg] Some video questions
On Jan 29, 2008, at 5:11 PM, Charles wrote: Dave, What am I missing that you don't like? Are Adobe/Microsoft going to be update their Flash/Silverlight browser plug-ins in order to be first-class video handlers in Safari on Mac and Windows? I think that would be a question for Adobe and Microsoft. But I think the premise of the question misses the point of the video element. People now commonly use Flash to write video players because the old-school way of embedding video (using object/embed with QuickTime, Windows Media, Real or other plugins) was not capable or consistent enough. Note that this change happened relatively recently however. Web developers are willing to switch deployment technology if there is enough advantage to doing so. video is a mechanism intended to give enough capabilities to write useful web video players in HTML+JS+CSS (with reasonable defaults for people who don't want to go to a lot of effort). It is designed to embed video, not video players implemented in other technologies. It is a video player, not a video player player. Regards, Maciej
Re: [whatwg] Some video questions
Darin, Are Adobe/Microsoft going to be update their Flash/Silverlight browser plug-ins in order to be first-class video handlers Why would they? Those aren't video plug-ins. They're general purpose applet plug-ins. That's a false distinction. QuickTime is capable of far more than simply non-interactive video/audio playback. http://books.google.com/books?id=YeQVZ9WbmHgC What distinguishes whether something is video or not is the content. -- Charles
Re: [whatwg] Some video questions
Maciej, But I think the premise of the question misses the point of the video element. I may very well be completely missing the point. I'll be satisfied if someone tells me that video is not intended to be the preferred way to embed video on web pages, in which case I'll quietly return to my corner. People now commonly use Flash to write video players because the old-school way of embedding video [...] was not capable or consistent enough. There are lots of reasons that people use Flash, but it's no easier or harder to embed than any other player/runtime. It is designed to embed video, not video players implemented in other technologies. But in Safari, video = QuickTime. Is that not a player-centric rather than a content-centric design? -- Charles
Re: [whatwg] Some video questions
On Jan 29, 2008, at 6:17 PM, Charles wrote: Maciej, But I think the premise of the question misses the point of the video element. I may very well be completely missing the point. I'll be satisfied if someone tells me that video is not intended to be the preferred way to embed video on web pages, in which case I'll quietly return to my corner. That is the goal. But you seem to think that this requires being a Flash or even Silverlight container, and I disagree that this is relevant to the goal. People now commonly use Flash to write video players because the old-school way of embedding video [...] was not capable or consistent enough. There are lots of reasons that people use Flash, but it's no easier or harder to embed than any other player/runtime. I mentioned capabilities (in particular the ability to build rich custom controls with custom branding) and consistency (Flash is more widely available than any single video plugin). Not ease of embedding. It is designed to embed video, not video players implemented in other technologies. But in Safari, video = QuickTime. Is that not a player-centric rather than a content-centric design? QuickTime is an implementation detail. To the extent that we promise support for specific video formats, it will be based on the format, not the implementation technology, and we reserve the right to change the back end for some or all video formats. In any case, QuickTime is a technology for playing back video (and audio), not a technology for running content that might implement a media player. It is not parallel to Flash. Flash is more akin to applet technologies like Java. Regards, Maciej
Re: [whatwg] Some video questions
On 29/01/2008, at 6:17 PM, Charles wrote: Maciej, But I think the premise of the question misses the point of the video element. I may very well be completely missing the point. I'll be satisfied if someone tells me that video is not intended to be the preferred way to embed video on web pages, in which case I'll quietly return to my corner. It is the preferred way to embed *video* not a video player, just pure unadorned video -- there is no direct interface to the underlying implementation. You appear to be having difficulty distinguishing QuickTime the plugin, from QuickTime the framework -- On MacOS quicktime is the standard system framework that applications use for decoding video -- it is equivalent (in this sense) to gstreamer in gtk, etc. video is *not* an object replacement -- its sole purpose is to provide support for video content that is native to html, and through player can be implemented and controlled through JS and CSS. People now commonly use Flash to write video players because the old-school way of embedding video [...] was not capable or consistent enough. There are lots of reasons that people use Flash, but it's no easier or harder to embed than any other player/runtime. It is designed to embed video, not video players implemented in other technologies. But in Safari, video = QuickTime. Is that not a player-centric rather than a content-centric design? Once again, video is a html-native mechanism for supporting video media, not a plugin interface there is no sense in having other runtimes present in it as that would defy the whole idea of being *native* --Oliver -- Charles
Re: [whatwg] Some video questions
Hi Charles, You are correct that the current draft leaves this aspect of the controls attribute unspecified. The video implementation available in the WebKit nightlies uses overlay controls that fade away during playback and don't affect the size of the video box. I saw a Firefox demo of this feature that took similar approach as well. antti On Jan 27, 2008, at 14:06, Charles [EMAIL PROTECTED] wrote: Hello, Apologies in advance if I've missed these details in the specification. The video element supports width and height. Does this include the additional area needed (if necessary) by the controls? It strikes me that it shouldn't, since it would be odd for the video width and height to change when non-video decorators are shown/ hidden. I don't see a standard controls height and width, which is fine, but will there be read-only attributes for the width, height and position for controls? -- Charles
Re: [whatwg] Some video questions
On Sun, 27 Jan 2008 23:06:53 +0100, Charles [EMAIL PROTECTED] wrote: Apologies in advance if I've missed these details in the specification. The video element supports width and height. Does this include the additional area needed (if necessary) by the controls? It strikes me that it shouldn't, since it would be odd for the video width and height to change when non-video decorators are shown/hidden. They do affect that area as far as I can tell. They give the height and width of the video player. I don't see a standard controls height and width, which is fine, but will there be read-only attributes for the width, height and position for controls? There are readonly attributes to get the height and width of the video. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Some video questions
Antti, Thanks for the response. The video implementation available in the WebKit nightlies uses overlay controls that fade away during playback and don't affect the size of the video box. I saw a Firefox demo of this feature that took similar approach as well. Does WebKit do this whether the plug-in handling the format is QuickTime, Windows Media/Silverlight, Flash, etc.? If users do show the video element's controls, are the plug-in's native controls shown? And when that happens, does the video element's height attribute then change if though the video's actual height hasn't changed? If that's the case, is the expectation that authors will need to temporarily hide controls (or make sure they're already hidden) before getting its height? -- Charles
Re: [whatwg] Some video questions
On 28.1.2008, at 13:51, Charles wrote: Antti, Thanks for the response. The video implementation available in the WebKit nightlies uses overlay controls that fade away during playback and don't affect the size of the video box. I saw a Firefox demo of this feature that took similar approach as well. Does WebKit do this whether the plug-in handling the format is QuickTime, Windows Media/Silverlight, Flash, etc.? If users do show the video element's controls, are the plug-in's native controls shown? And when that happens, does the video element's height attribute then change if though the video's actual height hasn't changed? The video element offers an interface to the native media playback capabilities of the platform. It is not a plug-in mechanism and it is not suitable for embedding things like Flash or Silverlight. There are existing mechanisms for that. Since there is no plug-in the concept of plug-in's native controls is not really applicable. antti If that's the case, is the expectation that authors will need to temporarily hide controls (or make sure they're already hidden) before getting its height? -- Charles
Re: [whatwg] Some video questions
The video element offers an interface to the native media playback capabilities of the platform. The browser platform (e.g. WebKit), the multimedia platform (e.g. QuickTime) or the OS platform (e.g. Mac OS X)? It is not a plug-in mechanism and it is not suitable for embedding things like Flash or Silverlight. So for Safari on both Macintosh and Windows, is Apple's intent that video will only work for formats supported by QuickTime? And given that little internet content targets QuickTime, who exactly will be using the video tag? Sorry if these seem like really stupid questions, but these don't seem to be addressed by the spec. -- Charles
Re: [whatwg] Some video questions
On Jan 29, 2008, at 01:32, Charles wrote: So for Safari on both Macintosh and Windows, is Apple's intent that video will only work for formats supported by QuickTime? And given that little internet content targets QuickTime, who exactly will be using the video tag? Even though video codecs aren't pluggable on the browser level in Safari, they are pluggable on the QuickTime level. For example, XiphQT enables Ogg/Theora/Vorbis support in QuickTime. Flip4Mac enables WMV support. MPEG-4 support is part of QuickTime itself. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Some video questions
Hi Charles, It was my understanding that video controls should be able to be added through style sheet mechanisms. Thus, there is no pre-set specification, but it is rather left to the web page designer. The javascript API will allow to hook up the controls with the video player. The controls could be overlayed over the video or added to any side of it or left out completely - just as the web page designer desires. Thus, they are outside the specification of the standard, IIUC. Regards, Silvia. On Jan 28, 2008 9:06 AM, Charles [EMAIL PROTECTED] wrote: Hello, Apologies in advance if I've missed these details in the specification. The video element supports width and height. Does this include the additional area needed (if necessary) by the controls? It strikes me that it shouldn't, since it would be odd for the video width and height to change when non-video decorators are shown/hidden. I don't see a standard controls height and width, which is fine, but will there be read-only attributes for the width, height and position for controls? -- Charles
