Re: [whatwg] video element proposal
Håkon Wium Lie schrieb: Does Dirac aim at becoming a member in the Ogg family, or are you primarily working towards a standalone format? Dirac is container neutral to my knowledge. The implementation targeted at end-users is embedding it in Ogg, though, so it can e.g. use the free Ogg audio codecs like Vorbis, FLAC and Speex. http://schrodinger.sourceforge.net/ So yeah, albeit it's not a codec developed by xiph.org themselves it's also (but not exclusively) part of the Ogg family.
Re: [whatwg] video element proposal
Hi Having been pointed at this discussion by Christian, I thought I'd let you know a bit more about where Dirac is as a royalty-free open source codec. We're certainly very keen for Dirac to be considered as one of the supported video formats. Dirac has been in development for 4 years. In compression terms it's about twice as efficient as MPEG2, competitive with H264 and VC-1 and substantially more efficient than Theora. The Dirac sourceforge site contains a full specification of the system which is very nearly complete. A subset of this, relating to professional profiles for TV production, has already been proposed to the SMPTE for standardisation as VC-2. Assuming that there are no roadblocks in this process, we intend to submit the rest of the Dirac system as VC-3 (or whatever number they're up to) towards the end of the year. So this time next year, there is a good chance that Dirac will be an international, royalty-free SMPTE standard. When we started Dirac, our intention was that the Dirac software on the website could be developed to build a real-time system. However, it proved difficult to make a system that could be a reference codec for testing the specification/draft standard and which had real-time optimisations. So in conjunction with Fluendo, we started the Schrodinger project (http://schrodinger.sf.net) which is a real-time, multi-platform implementation of Dirac being developed in parallel with the Dirac software. This isn't quite finished yet, but we will have a compliant alpha release in the next month or two. It will be alpha because although it will do real-time encoding and decoding in software, it won't compress all that well. The Dirac site software is being maintained as a reference and demonstrator system. Our aim then is to do a beta release of Schrodinger by the autumn using all the encoder optimisations in Dirac, so by the end of the year we should be there in terms of having a really good, efficient real-time encoder and decoder. Third parties can start designing implementations when the spec is finalised at version 1.0 in only a couple of weeks from now. We have been developing Dirac hardware as well. Hardware for the professional applications will be on sale in a very few weeks, and we're developing a prototype hardware HDTV encoder too. Thomas http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
Re: [whatwg] video element proposal
This is maybe off-topic to some degree. What are the DRM constraints of this format? I only ask as your organisation is embarking on an MS-DRM fueled online media project, and I am curious as to the position of this codec. thanks On 22 Mar 2007, at 12:28, Thomas Davies wrote: Hi Having been pointed at this discussion by Christian, I thought I'd let you know a bit more about where Dirac is as a royalty-free open source codec. We're certainly very keen for Dirac to be considered as one of the supported video formats. Dirac has been in development for 4 years. In compression terms it's about twice as efficient as MPEG2, competitive with H264 and VC-1 and substantially more efficient than Theora. The Dirac sourceforge site contains a full specification of the system which is very nearly complete. A subset of this, relating to professional profiles for TV production, has already been proposed to the SMPTE for standardisation as VC-2. Assuming that there are no roadblocks in this process, we intend to submit the rest of the Dirac system as VC-3 (or whatever number they're up to) towards the end of the year. So this time next year, there is a good chance that Dirac will be an international, royalty-free SMPTE standard. When we started Dirac, our intention was that the Dirac software on the website could be developed to build a real-time system. However, it proved difficult to make a system that could be a reference codec for testing the specification/draft standard and which had real-time optimisations. So in conjunction with Fluendo, we started the Schrodinger project (http://schrodinger.sf.net) which is a real-time, multi-platform implementation of Dirac being developed in parallel with the Dirac software. This isn't quite finished yet, but we will have a compliant alpha release in the next month or two. It will be alpha because although it will do real-time encoding and decoding in software, it won't compress all that well. The Dirac site software is being maintained as a reference and demonstrator system. Our aim then is to do a beta release of Schrodinger by the autumn using all the encoder optimisations in Dirac, so by the end of the year we should be there in terms of having a really good, efficient real-time encoder and decoder. Third parties can start designing implementations when the spec is finalised at version 1.0 in only a couple of weeks from now. We have been developing Dirac hardware as well. Hardware for the professional applications will be on sale in a very few weeks, and we're developing a prototype hardware HDTV encoder too. Thomas http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
Re: [whatwg] video element proposal
Dirac is _just_ a video codec - there are no DRM components in the system. regards Thomas From: Gareth Hay [mailto:[EMAIL PROTECTED] Sent: 22 March 2007 12:51 To: Thomas Davies Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] video element proposal This is maybe off-topic to some degree. What are the DRM constraints of this format? I only ask as your organisation is embarking on an MS-DRM fueled online media project, and I am curious as to the position of this codec. thanks On 22 Mar 2007, at 12:28, Thomas Davies wrote: Hi Having been pointed at this discussion by Christian, I thought I'd let you know a bit more about where Dirac is as a royalty-free open source codec. We're certainly very keen for Dirac to be considered as one of the supported video formats. Dirac has been in development for 4 years. In compression terms it's about twice as efficient as MPEG2, competitive with H264 and VC-1 and substantially more efficient than Theora. The Dirac sourceforge site contains a full specification of the system which is very nearly complete. A subset of this, relating to professional profiles for TV production, has already been proposed to the SMPTE for standardisation as VC-2. Assuming that there are no roadblocks in this process, we intend to submit the rest of the Dirac system as VC-3 (or whatever number they're up to) towards the end of the year. So this time next year, there is a good chance that Dirac will be an international, royalty-free SMPTE standard. When we started Dirac, our intention was that the Dirac software on the website could be developed to build a real-time system. However, it proved difficult to make a system that could be a reference codec for testing the specification/draft standard and which had real-time optimisations. So in conjunction with Fluendo, we started the Schrodinger project (http://schrodinger.sf.net http://schrodinger.sf.net ) which is a real-time, multi-platform implementation of Dirac being developed in parallel with the Dirac software. This isn't quite finished yet, but we will have a compliant alpha release in the next month or two. It will be alpha because although it will do real-time encoding and decoding in software, it won't compress all that well. The Dirac site software is being maintained as a reference and demonstrator system. Our aim then is to do a beta release of Schrodinger by the autumn using all the encoder optimisations in Dirac, so by the end of the year we should be there in terms of having a really good, efficient real-time encoder and decoder. Third parties can start designing implementations when the spec is finalised at version 1.0 in only a couple of weeks from now. We have been developing Dirac hardware as well. Hardware for the professional applications will be on sale in a very few weeks, and we're developing a prototype hardware HDTV encoder too. Thomas http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
Re: [whatwg] video element proposal
Once upon a time Maik Merten shaped the electrons to say... Well, I guess everybody here will hate me for proposing it... and I think it's ugly... but well... video Perhaps a verbose description of what can be seen here? novideo D'oh, your browser is outdated... let's embed an object here /novideo /video Just as we have been able to do object embed /embed /object To support legacy UAs which don't handle object, why not: video object /object /video Just as with object, the specification would have the UA stop at the outer-most container it can render. (I know IE6 failed to do this.) -MZ -- URL:mailto:megazoneatmegazone.org Gweep, Discordian, Author, Engineer, me. A little nonsense now and then, is relished by the wisest men 508-852-2171 URL:http://www.megazone.org/ URL:http://www.eyrie-productions.com/ Eris
Re: [whatwg] video element proposal
Håkon Wium Lie schrieb: In the context of codecs, the term performance is most often used to describe compression ratios (at given levels of quality). There is another factor related to performace which is also relevant when picking the best codec for the web: how much processing power does a given format need? I believe, in general, that the higher performace a codec has, the more processing power it requires. As a result, it may be impossible to decode a high-performance video format on some devices. I'm not an expert in video coding, just an interested layman. So take whatever I say with a grain of salt. I hope that if I happen to spread wrong information someone will step up and correct things. As a rule of thumb powerful codecs usually need more processing power than not so powerful codecs. From MPEG 1 to MPEG 4 Part 10 (H.264) there's a steady increase in processing complexity. In case of Theora the decoding requirements are in the same league as MPEG 4 Part 2 (the original MPEG4 video codec, most widely known by XviD or DivX), perhaps a bit lighter - and the format itself is targeted at achieving similar compression results. H.264 is much more complex. I have no concrete numbers (those would depend on the exact circumstances anyway) but many devices that cope with MPEG4 Part 2 are vastly out of luck with H.264. Mobile devices playing H.264 usually have DSPs on-board to help with the decoding tasks - and even then they still don't cope with the more complex profiles H.264 has to offer. The iPod Video only supports the Baseline Profile according to http://www.apple.com/ipod/specs.html , which is the profile of lowest complexity available. According to http://electronics.howstuffworks.com/ipod3.htm their iPod used special video processing hardware ( http://www.broadcom.com/products/Cellular/Mobile-Multimedia-Processors/BCM2722 ) to play video. I'd think browser vendors usually can't rely on DSPs when it comes to mobile applications. I only know some data points for Theora, but I think MPEG4 Part 2 should behave similiar. On the Nokia N800 internet tablet Theora at 352x208 resolution decodes with ~45% cpu usage using the feature complete theora-exp decoder which will become the new reference decoder. The Nokia N800 seems to use an OMAP2420 microprocessor. It includes an ARM core and DSP units for multimedia processing. The decoder, however, is written in plain C without optimized code for ARM and with no support for the DSP features at all. http://maemo.org/pipermail/maemo-developers/2007-February/008138.html (At that time it seems the integer-only Vorbis decoder (Tremor) wasn't yet working on the N800, so they had to use the floating point decoder not really suitable for that hardware platform. These problems are resolved by now if I understood correctly.) Another data point is the OLPC 100$ Notebook hardware. That one is using an AMD Geode [EMAIL PROTECTED], which is basically a Cyrix MediaGX (later renamed to National Semiconductor Geode, then sold to AMD) at 366 MHz. It's using a x86 compatible core roughly being Pentium-I class when it comes to integer performance and supporting MMX instructions. Actually I think there may be more powerful cell phones out there when it comes to raw processing power ;) The OLPC hardware is capable of decoding Theora in QCIF (352x288) resolution in realtime (that's mostly a worst case estimate for content with much movement). For accessing video content on e.g. Wikipedia that should suffice, though. Therefore, on the web, a high-performance format may not be suitable as it excludes devices with limited processing power. On the other hand, these devices may also have limited connectivity so compression is called for. It's more or a less a tradeoff situation. If you double the processing requirements you usually don't come even close to doubling the coding efficiency. If you can't use special hardware you often end up not having a choice but to choose a codec of moderate complexity. Maik Merten
Re: [whatwg] video element proposal
Bjoern Hoehrmann [EMAIL PROTECTED] wrote: It is hard to find tools that take care of transcoding, they are difficult to use (lack of advise on which settings to use, crude command line interfaces, ...) Most such applications start as console applications, that changes as soon as more mainstream interest and usage results. and using Ogg Theora generally meant considerably reducing the quality while at the same time considerably increasing file size, not to mention that going from various of the formats I had meant going from works almost everywhere to works almost nowhere. Transcoding from one lossy format that is used on the web to another results in a significant reduction in quality compared to a non lossy source to lossy end format encoding, so you shouldn't make quality vs file size judgements based on that type of transcoding. -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] video element proposal
Anne van Kesteren wrote: We're not enforcing this upon the world ;-) Speaking about enforcing. When this element gets implemented there are a few things I would demand from my browser: 1. That videos should never start to play without my consent. No more bgsound-hellish experiences. Advertisers will protest, but I'd say it is up to them to make their commercials so appealing that I'd want to play the video in question. 1b. If not (1) That video does not play automatically in a window/tab that does not sit in the foreground. I tend to scroll wheel click on links a lot. if there is video content on the page that has just opened behind the one I am currently in and I would like to watch it, I'd definitely prefer to start it when I flip tabs. 2. I would like greater control than just start, stop, pause, forward, back and perhaps moving a slider. Looking at this: http://video.yahoo.com/video/play?vid=cccd4aa02a3993ab06e56af731346f78.2006940 Would it not be great if I could *navigate* to different parts of the video according to some headlines: - Douglas C: opening - Chris Wilson on... - Chris Wilson on... ... - Håkon Wium Lie on ACID 2 - Håkon Wium Lie on the proposed video element Etc Instead of relying on notes saying: So and so starts x minutes into the video. Perhaps some sort of goto function with associated labels? Lars Gunther
Re: [whatwg] video element proposal
Bjoern Hoehrmann schrieb: Flash supports two codecs, the more recent one is VP6, a successor of VP3; VP3 in turn is what Ogg Theora is based on. I would be surprised to learn that On2 gave the superior codec away for free while it sells the inferior one. On2 VP6 is performing better than On2 VP3, on which Theora is based. However, the original VP3 encoder IIRC had a few quality impacting bugs, those are fixed in the Theora reference encoder. Plus the spec for Theora has been extended to overcome some limitations that were present in the original VP3 (the reference encoder doesn't use these new bitstream features yet, so there's room for improvement over what we see today). To put it into a nutshell: Theora is not just VP3 in an Ogg container. It's a descendant to VP3 just like VP4, VP5, VP6... I can't comment on how Theora compares to VP6, but I'm pretty sure Theora outperforms H.263 which is said to be used at Google Video or YouTube for compatibility reasons. One example, using the football VQEG sequence (deinterlaced with a linear blend deinterlacer, cropped to remove black borders, YV12, uncompressed YUV4MPEG2 input): ffmpeg2theora -x 352 -y 288 --aspect 4:3 -K 512 -v 0.5 football.yuv http://datadump.da.funpic.de/football.ogg (474K) mencoder -vf scale=352:288 -ovc lavc -lavcopts vcodec=h263:vhq:vqscale=18:trell:keyint=512 -o football-h263.avi football.yuv http://datadump.da.funpic.de/football-h263.avi (478K) As far as I know the ffmpeg H.263 encoder implementation used by mencoder is of rather good quality and I tried to use the best settings available. Anyway, this of course is no extensive benchmark at all (and this list would be the wrong place anyway) but I think it gives a first impression. Personally I think the current draft by Ian Hickson (UAs SHOULD support Theora for video and Vorbis for audio, and SHOULD support the Ogg container format) makes a lot of sense as it encourages the adoption of one base format people can rely on and still doesn't hinder innovation on the codec side.
Re: [whatwg] video element proposal
On Fri, 16 Mar 2007 23:49:04 -, Bjoern Hoehrmann [EMAIL PROTECTED] wrote: ++-+-+---+ | SMIL | SVG | IE | WHATWG | ++-+-+---+ beginElement() | beginElement() | beginElement() | play() endElement() | endElement()| endElement()| stop() - | pauseElement() | pauseElement() | pause() - | resumeElement() | resumeElement() | togglePause() - | isPaused| isPaused| state == PAUSED ... I think that nomenclature in WHATWG's API is much simpler and straightforward and that outweights benefit of appealing to authors experienced with SMIL/SVG. beginElement() may sound strange and confusing to authors, especially ones familiar only with W3C DOM (where names like getElementById or createElement are often used). OTOH anyone can guess what play() and stop() do. +--+-+ | Flash/ActionScript | WHATWG| +--+-+ pause() | togglePause() pause(true) | pause() pause(false) | togglePause() seek(s) | seek(1000 * s) time | position / 1000 This however is a good point - since Flash became de-facto standard for publishing video on the web, authors are likely to know Flash's API already. Having similar, but not exactly the same API may be source of mistakes. -- regards, Kornel Lesiński
Re: [whatwg] video element proposal
I'm refereeing at the Silicon Valley regionals of the FIRST Robotics Challenge, so I'm not able to respond to the thread and fix the spec appropriately yet (though I'll get right on that next week), but I just wanted to correct a minor error in this mail: On Sat, 17 Mar 2007, Bjoern Hoehrmann wrote: ++-+-+---+ | SMIL | SVG | IE | WHATWG | ++-+-+---+ beginElement() | beginElement() | beginElement() | play() endElement() | endElement()| endElement()| stop() - | pauseElement() | pauseElement() | pause() - | resumeElement() | resumeElement() | togglePause() - | isPaused| isPaused| state == PAUSED resumeElement() is like play(), not like togglePause(). +--+-+ | Flash/ActionScript | WHATWG| +--+-+ pause() | togglePause() pause(true) | pause() pause(false) | togglePause() These are also wrong. They should be: pause()togglePause() pause(true)pause() pause(false) play() There are (good?) reasons for the differences; I looked at the Flash API very closely. I'll reply in more detail next week. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video element proposal
Also sprach Maik Merten: I can't comment on how Theora compares to VP6, but I'm pretty sure Theora outperforms H.263 which is said to be used at Google Video or YouTube for compatibility reasons. Thank you for an informative message on video decoders. In the context of codecs, the term performance is most often used to describe compression ratios (at given levels of quality). There is another factor related to performace which is also relevant when picking the best codec for the web: how much processing power does a given format need? I believe, in general, that the higher performace a codec has, the more processing power it requires. As a result, it may be impossible to decode a high-performance video format on some devices. Therefore, on the web, a high-performance format may not be suitable as it excludes devices with limited processing power. On the other hand, these devices may also have limited connectivity so compression is called for. It would be interesting to see a comparison of video quality vs. processing requirements. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] video element proposal
* Håkon Wium Lie wrote: Namespaces are hard and I doubt that any markup that requires using them will succeed. Also, the vendor-specific string is troublesome for general use. If we want to make video a first-class citizen on the web (and I think we do) we can afford to give it its own element in HTML. The name and attributes can be borrowed from other specs, but the element itself should be in HTML. Second, about the codecs. I believe it's vital that we find a video format that is sufficiently open. It should be described in a freely available specification and there should be no (known or unresolved) patent claims. I don't think this is the case for the codecs on the other side of the t:video element. Yes, well, there are only so and so many variables you can optimize for. So let me just pick some and see where we stand. The first is, I want to leverage my knowledge of related technologies like SMIL, SVG, and Flash. This is important, for example, if I start with a plain HTML video page and later want a more sophisticated interface with vector graphics, ani- mation and so on, so I might switch from HTML to XHTML+SVG. Here is how we fare for some basic features: ++-+-+---+ | SMIL | SVG | IE | WHATWG | ++-+-+---+ beginElement() | beginElement() | beginElement() | play() endElement() | endElement()| endElement()| stop() - | pauseElement() | pauseElement() | pause() - | resumeElement() | resumeElement() | togglePause() - | isPaused| isPaused| state == PAUSED ... We can also compare with Flash: +--+-+ | Flash/ActionScript | WHATWG| +--+-+ pause() | togglePause() pause(true) | pause() pause(false) | togglePause() seek(s) | seek(1000 * s) time | position / 1000 ... So if I move from xhtml:video to svg:video or smil:video or ie:video, I would have to rewrite most of my scripts, whereas moving between the others can be done effortlessly. Web application technologies should be based on technologies authors are familiar with, except when you don't feel like it? The next is compatibility. I want my content to work in as many cases as possible. It goes without saying that WHATWG video works nowhere. I think Any solution that cannot be used with the current high-market- share user agent without the need for binary plug-ins is highly unlikely to be successful. Clearly WHATWG video cannot be made to work in IE either because at the very least that would require making the internal representation of the document invalid. I cannot effort that, as some people would think I might be actively sabotaging the work of web standards and W3C, or at the very least, be demonstrating an almost unbelievable lack of competence. So you can consider web standards compliance a third item in my list (I understand this is not shared by WHATWG, as using tag soup is considered a reasonable transition strategy). As for codecs, I recently had to put a bunch of my old videos into a form that I could publish and did try to use sufficiently open formats. Some of my findings are in the logs on http://swhack.com/, but to give a quick summary: that's far from working as yet. It is hard to find tools that take care of transcoding, they are difficult to use (lack of advise on which settings to use, crude command line interfaces, ...) and using Ogg Theora generally meant considerably reducing the quality while at the same time considerably increasing file size, not to mention that going from various of the formats I had meant going from works almost everywhere to works almost nowhere. For some of them I could not find free tools at all, and in a few cases I could find no tools whatsoever (old Intel Indeo encoded AVIs created under Win3.11, I have the codecs somewhere on backups, but they are not on the web and apparently not implemented independently, so much for proprietary formats). It would be easier, of course, if I still had the raw video data and could encode it directly, just like you get better HTML if you just write the HTML directly instead of going through your Word process and several conversion layers, but I don't have them. So, where does that leave me? Ah, yes, Page xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation; MediaElement Source=example.video / /Page which, too, has the benefit of actually working in my web browser. It also happens to be much simpler than the equivalent HTML5 document. So, sure, don't pick the not-invented-here APIs,
Re: [whatwg] video element proposal
Also sprach Bjoern Hoehrmann: ++-+-+---+ | SMIL | SVG | IE | WHATWG | ++-+-+---+ beginElement() | beginElement() | beginElement() | play() endElement() | endElement()| endElement()| stop() - | pauseElement() | pauseElement() | pause() - | resumeElement() | resumeElement() | togglePause() - | isPaused| isPaused| state == PAUSED ... I personallay think play, stop and pause are better names. So, sure, don't pick the not-invented-here APIs We didn't really invent play, stop, pause. These words are printed on at least fire remote controls within easy reach of me at the moment. Do you really think using beginElement would be better? The next is compatibility. I want my content to work in as many cases as possible. It goes without saying that WHATWG video works nowhere. I think Any solution that cannot be used with the current high-market- share user agent without the need for binary plug-ins is highly unlikely to be successful. This is an issue. I don't know if will be possible to extend IEx to support video/OggTheora without Microsoft's consent. IEx has proven to be amazingly extensible in the past. We'll see. Even if it turns out to be impossible to use open codecs in IEx, people should still be encouraged to use open codecs. It is hard to find tools that take care of transcoding, they are difficult to use (lack of advise on which settings to use, crude command line interfaces, ...) and using Ogg Theora generally meant considerably reducing the quality while at the same time considerably increasing file size Compared to which formats? I believe Ogg Theora performs better than Flash. Given the video quality of some of the superhits on YouTube, I doubt this is the most important factor, though. So, where does that leave me? Ah, yes, Page xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation; MediaElement Source=example.video / /Page which, too, has the benefit of actually working in my web browser. It also happens to be much simpler than the equivalent HTML5 document. It doesn't work in my browser. What does the code do? -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] video element proposal
On Mar 16, 2007, at 5:29 PM, Håkon Wium Lie wrote: Compared to which formats? I believe Ogg Theora performs better than Flash. Given the video quality of some of the superhits on YouTube, I doubt this is the most important factor, though. Ogg Theora is based on the VP3 codec [1] that flash video uses. [2] The Theora site says the main differences are architectural. After reading past their techno speak, it looks like Theora MAY be able to create better video with it's encoder than Flash can at a given bit rate. If YouTube is what you are basing your comparison on, they probably have pretty crappy conversion settings to save bandwidth. I haven't done / seen any comparisons between Theora and FLV in a controlled environment. They may turn out to create fairly similar video quality at fairly similar sizes. Hopefully people don't expect super-high-quality video on the web. It's possible, but it isn't practical for most site owners. However, the quality decisions will be left up to the person encoding the video, not the player. [1] http://www.theora.org/theorafaq.html#20 [2] http://www.on2.com/technology/flix_praise/ -- Robert http://robertdot.org
Re: [whatwg] video element proposal
* Håkon Wium Lie wrote:
Do you really think using beginElement would be better?
Do you really think using two different methods to trigger playback of
svg:video and xhtml:video elements is better than using a single method?
Or what about different methods to trigger an animation or transition
effect versus multimedia content playback? Let's extend my example:
t:video id='video'
begin='play.click'
end='stop.click'
src='example.video'
t:transitionFilter begin=video.begin
type='barnDoorWipe'
dur=5 /
/t:video
pinput type='button' value='Play!' id='play' /
input type='button' value='Stop!' id='stop' /
Here the playback of the video begins when the play control is clicked,
and the barnDoorWipe transition effect on the video will begin in turn
when playback of the video begins. The begin attribute is quite flex-
ible, I might change the example so playback of the video begins auto-
matically 2 seconds after the document began:
t:video id='video'
begin='2s; play.click'
end='stop.click'
src='example.video'
or I might just drop the controls and just let it begin at 2s:
t:video begin='2s' src='example.video' /
You said 'play' might be a better name, so let's just use that for a
moment:
t:video play='2s' src='example.video' /
That does not look so much better to me, I would think this plays for
two seconds, not to start playing after two seconds have elapsed. I
also would not consider a transition effect as I've used it above to
play, and animation effects also don't really play for me. I do
think that common timing control attributes and APIs are a good thing,
and play turns out to be much less flexible than begin. So, no, I
do not agree that play is a better name, even if it was 1997 and we
would have the opportunity to pick a different name.
This is an issue. I don't know if will be possible to extend IEx to
support video/OggTheora without Microsoft's consent. IEx has proven
to be amazingly extensible in the past. We'll see.
It does not seem very likely that Microsoft will ship the codec out of
the box in the forseeable future, but sure, you can easily install more
codecs manually on the system and Internet Explorer will automatically
support them. I understand it is quite common to install a DivX codec,
for example.
Compared to which formats? I believe Ogg Theora performs better than
Flash. Given the video quality of some of the superhits on YouTube, I
doubt this is the most important factor, though.
Flash supports two codecs, the more recent one is VP6, a successor of
VP3; VP3 in turn is what Ogg Theora is based on. I would be surprised
to learn that On2 gave the superior codec away for free while it sells
the inferior one. http://www.demoscene.tv/ uses VP6 (independently of
Flash, you need a separate plugin or application) and notes in its FAQ:
Why don't you use another video codec than ON2's VP6,
that would be more cross-platform ?
We use that codec in order to provide the best quality
to the Demoscene. It has the best quality/bandwidth
especially for low bandwidth (ie a web TV) You'll find
more [on http://www.on2.com/].
That's not so much the issue in my case though, I don't have high
quality input and just have to pick my favourite codec, I have input
that is already compressed using proprietary lossy codecs, recoding
almost necessarily decreases quality, and in my cases considerably
increases file size (formats include Xvid, rmvb, mp43, and others,
most of them are at least as widely deployed as Ogg Theora).
It doesn't work in my browser. What does the code do?
It just plays the video back, where the video is positioned and scaled
as the typical media player would do (it's scaled to fit the browser
window while preserving the aspect ratio, and centered in the space
left to fill). I would have given the HTML5 equivalent but I could
not think of a simple solution for this. It would probably be some-
thing like
body, html { margin: 0; padding: 0 }
body { height: 100%; width:100% }
video {
fit: meet;
fit-position: center;
}
or
html, body { margin: 0; padding: 0 }
video {
position: center; aspect-ratio: preserve;
height: 1vh; width: 1vw;
}
along with doctype, title element, and so on. But when writing this
I started wondering why video? Isn't this really just a HTML frag-
ment with an alternate motion picture representation with optional
sound, much like img?
--
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] video element proposal
Bjoern Hoehrmann wrote: In case of video, there is no need to implement anything using style sheets, behaviors, or scripting, you can use it directly, right now, it's easy as pie, html xmlns:t=urn:schemas-microsoft-com:time ?import namespace=t implementation=#default#time2 body t:video src='example.video'/t:video /body and based on an open W3C standard. No need for separate languages at all. Interesting. What video formats will it play? Anything Windows has a codec for? Can it be controlled via script? Does it support fallback content? Gerv
Re: [whatwg] video element proposal
* Stuart Langridge wrote: Of course, this only works with stuff that WMP can already play, which will make backending a proposed video tag to this impractical (since you can't mandate a format that Windows doesn't have, in particular Ogg *, and there are doubtless issues with mandating formats that Windows *does* have). But it's interesting, nonetheless. It is my understanding that third party applications like for example the illiminable Ogg Directshow Filter can be used to enable playback of additional formats not natively supported by Windows Media Player. Internet Explorer does not include any kind of artificial restrictions in this area, if you have a Xvid codec installed, you can use it to playback Xvid. Similarily, Microsoft could support any mandated format in future ver- sions. Of course, expecting Microsoft to adopt formats in direct com- petition with its own technologies and that of its partners, that are not compatible with a wide range of existing devices and not widely used at all, is not particularily reasonable. But yes, IE compatibility and mandatory video formats not supported by IE are mutually exclusive. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] video element proposal
* Håkon Wium Lie wrote: I think we want to make video a first class citizen of the web. That means, IMHO, that there must be a simple way to add video to HTML pages. I don't think one shoulr rely on other languages for this, although I'm perfectly happy supporting those other languages as well. Part of the reason why we could to this so quickly is the work we have done on SVG. Absolutely, and http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera Basic Web application features should be implementable using behaviors, scripting, and style sheets in IE6 today so that authors have a clear migration path. In case of video, there is no need to implement anything using style sheets, behaviors, or scripting, you can use it directly, right now, it's easy as pie, html xmlns:t=urn:schemas-microsoft-com:time ?import namespace=t implementation=#default#time2 body t:video src='example.video'/t:video /body and based on an open W3C standard. No need for separate languages at all. It's not perfect, but the terrible design of XMLHttpRequest, canvas, and other features also did not prevent their inclusion in Web Applications 1.0. Don't you think the differences between the video features in IE5+, SMIL, SVG, and HTML should be minimized, and using them in IE be made as easy as technically feasible? -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] video element proposal
Maciej Stachowiak wrote: Restricting the types of content that the video element can handle will stifle future innovation, and will likely be ignored by browser vendors who decide they would like to support new formats. It would also be unprecedented relative to type restrictions on other HTML elements. Having a baseline set of formats is something to consider, but the spec should allow supporting any format that can reasonably considered video. Indeed. There's a big difference between mandating a baseline set of formats and stating that these are the _only_ formats that may be supported. Let's definitely do the former, and definitely not do the latter (and if we did, browser makers would probably ignore us eventually anyway). Gerv
Re: [whatwg] video element proposal
James Graham wrote: Widespread deployment (despite not working in many situations Flash has close enough to 100% of the desktop market for content producers to ignore the rest). In practice this means at least two things. Firstly, browser manufacturers without significant in-house video expertise should be able to implement the spec using an external library. Secondly it means that we should be able to implement it in existing versions of IE somehow. A good point. I know nothing about extending IE; would it be possible to have an IE addon which implemented support for a video tag, or would it need to be a plugin and therefore use object-style markup? While it's not as neat in spec terms, if it makes the difference between IE can't support it and IE can support it with additional software, then a carefully defined subset of object might be a better route than a new tag. Something like Any object tag with the following attributes exactly should be treated in the following fashion... (and from then on pretend it's a video tag). Gerv
Re: [whatwg] video element proposal
Gervase Markham schrieb: A good point. I know nothing about extending IE; would it be possible to have an IE addon which implemented support for a video tag, or would it need to be a plugin and therefore use object-style markup? Well, I guess everybody here will hate me for proposing it... and I think it's ugly... but well... video Perhaps a verbose description of what can be seen here? novideo D'oh, your browser is outdated... let's embed an object here /novideo /video Downside: Bloat. Upside: The author can either embed an object (e.g. in IE video would call the Windows Media Player - and that can be extended to support basically every media format - including MPEG, the Ogg formats (there is software for this in existance) or whatever else is out there) or simply tell the user to get a decent browser (yay, browser buttons all over again!). Plus it would feature a description of the video content for browsers that can't possibly display video (text browsers, mobile phones that don't have the bandwidth). Anyway: With external software it should be possible to get the IE to support a video tag. In worst case just grab the document source and substitue video with object and make sure the user has a fitting plugin for the mandatory format installed. Maik Merten
Re: [whatwg] video element proposal
* Gervase Markham wrote: A good point. I know nothing about extending IE; would it be possible to have an IE addon which implemented support for a video tag, or would it need to be a plugin and therefore use object-style markup? Why would you need an add-on? Internet Explorer has had support for a video element in HTML documents for pretty much the whole millenium, see http://www.w3.org/TR/1998/NOTE-HTMLplusTIME-19980918 for the spec and for a working example see e.g. http://www.w3.org/2001/SMIL20/testsuite/interop2/media/media_clipBegin_clipEnd_repeatCount.htm More up to date documentation is available from the MSDN, and from http://www.w3.org/TR/2002/NOTE-XHTMLplusSMIL-20020131/. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] video element proposal
Maik Merten wrote: Well, I guess everybody here will hate me for proposing it... and I think it's ugly... but well... video Perhaps a verbose description of what can be seen here? novideo D'oh, your browser is outdated... let's embed an object here /novideo /video I don't think we need a novideo element. This would work: video p Complete marked up transcript of the video. /p /video This is much more accessible and great for search engine optimization. Of course, not everyone has the resources to provide full transcripts all the time, but we should encourage that for those publishers that can. We can even throw in embed elements for users whose browsers don't recognize video. Must ignore wins again. :-) -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] video element proposal
On Tue, 06 Mar 2007 14:40:51 +0100, Elliotte Harold [EMAIL PROTECTED] wrote: I don't think we need a novideo element. This would work: video p Complete marked up transcript of the video. /p /video Yup, that was also in the proposal, fwiw. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] video element proposal
Elliotte Harold schrieb: Maik Merten wrote: I don't think we need a novideo element. This would work: video p Complete marked up transcript of the video. /p /video This is much more accessible and great for search engine optimization. This makes sense, although I'm not sure if it's always a good idea to mix legacy browsers handling with content that is supposed to be valuable for all browsers. Your full transcript would thus perhaps contain an object tag that isn't targeted at browsers supporting video but is nonetheless part of the content that is valuable for such browsers. I'm not sure if this actually is considered to be an issue. Maik Merten
Re: [whatwg] video element proposal
On Tue, 06 Mar 2007 10:11:01 -, Gervase Markham [EMAIL PROTECTED] wrote: A good point. I know nothing about extending IE; would it be possible to have an IE addon which implemented support for a video tag, or would it need to be a plugin and therefore use object-style markup? A script could easily fake video element using dynamically created object. That's almost what SWFObject/QTObject scripts do now (and that's probably de-facto standard for embedding interactive content since Eolas patent). I think in that case video is safest solution, because this gives acces to alternative content (which is broken in IE6's object) and allows script-controlled plugin detection and workarounds for bugs in plugins/browser. -- regards, Kornel Lesiński
Re: [whatwg] video element proposal
Gervase Markham schrieb: They estimate the increase in download size for a browser shipping Ogg + Theora-ng + Vorbis at 130k. Actually I took the liberty of trying to squeeze a functional set of Ogg decoding libraries into a small footprint (mainly by stripping binaries and using -Os instead of -O2/O3). I now have a 120K archive (tar.bzip2) that features: -rw-r--r-- 1 user users 12K 2007-03-05 14:47 libfishsound.a That's a convenience library to abstract the different Xiph.org audio codecs. My build only supports Vorbis. liboggplay uses this library. -rw-r--r-- 1 user users 8,4K 2007-03-05 16:12 libogg.a The low level Ogg container library. Used by all Ogg codecs. -rw-r--r-- 1 user users 14K 2007-03-05 14:47 liboggplay.a A high level playback library. This makes life easy *and* is making sure A/V sync is working crossplatform (this is not trivial). -rw-r--r-- 1 user users 25K 2007-03-05 14:47 liboggz.a An abstraction library that handles seeking etc. on Ogg streams. Needed by liboggplay. -rw-r--r-- 1 user users 1,7K 2007-03-05 14:47 libtheoracompat.a A small library to expose the usual libtheora API albeit libtheoradec is used. Needed by liboggplay. Once liboggplay can directly use the libtheoradec API it can be skipped. -rw-r--r-- 1 user users 45K 2007-03-05 14:47 libtheoradec.a That's a fast, complete and safe Theora decoder. It'll replace the current reference decoder at one point. -rw-r--r-- 1 user users 136K 2007-03-05 14:47 libvorbis.a The Vorbis decoder. It's a pretty big thing, but I'm told that it contains stuff like precomputed tables that could be computed on startup to reduce the disk footprint. I hope that covers all dependencies. If somebody wanted to dump the convenience libraries and wants to develop his own cross-platform playback system that does seeking and A/V sync you can get away with libvorbisdec, libtheoradec and libogg. Compressed that is 102 K. Maik Merten
Re: [whatwg] video element proposal
On Mar 4, 2007, at 16:31, Geoffrey Sneddon wrote: Also note that patents haven't stopped the web in the past (see: GIF). The fact that the Welch patent did not totally wreck the Web and did not cause browsers to drop GIF support should *not* be considered evidence of the harmlessness of patents. In the case of the Welch patent, there were two mitigating factors: 1) The patent (due to drafter incompetence, I presume) did not cover decompression, so it did not affect browsers. 2) It was possible to produce a bit stream that worked with the decompression algorithm but that was not actually compressessed the production method for this kind of bitstream did not infringe on the Welch patent. Some Free Software packages used this method to achieve compatibility while sacrificing actual compression. These mitigating factors are not generalizable, which makes GIF as a case study non-generalizable. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] video element proposal
Maciej Stachowiak wrote: Restricting the types of content that the video element can handle will stifle future innovation, and will likely be ignored by browser vendors who decide they would like to support new formats. It would also be unprecedented relative to type restrictions on other HTML elements. Having a baseline set of formats is something to consider, but the spec should allow supporting any format that can reasonably considered video. The spec could also consider urging /authors/ not to use formats only implemented in one or two browsers and to avoid proprietary formats where open ones are available ... unless we want to allow nesting video elements for fallback? Not that there's anything wrong with nested elements, seeing as we must offer text fallback anyhow, and seeing as the same API would be exposed by each nested level. -- Benjamin Hawkes-Lewis
Re: [whatwg] video element proposal
On 4 Mar 2007, at 14:08, Maik Merten wrote: - MPEG4: This is most common in forms of DivX and XviD. Predecessor of H.264. As usual there's patent pool licensing involved. This means that albeit XviD is open sourced it's not really free due to patent licensing issues. That's wrong – H.264 is MPEG4 Part 11 – it's part of the MPEG4 spec. I think we need to look at why the MPEG standards see near universal support and use: as you say, parts of MPEG4 are highly efficient (such as H.264 and AAC), whereas alternatives of things like Theora aren't anywhere near efficient. Also note that patents haven't stopped the web in the past (see: GIF). I really believe that this is too political, as history has shown people will use whatever formats can be created easily, and are well supported. It could be perfectly possible that anything wanting to implement the spec is put off by needing to support a single format that (almost) nobody uses. - Geoffrey Sneddon
Re: [whatwg] video element proposal
On 4 Mar 2007, at 14:31, Geoffrey Sneddon wrote: On 4 Mar 2007, at 14:08, Maik Merten wrote: - MPEG4: This is most common in forms of DivX and XviD. Predecessor of H.264. As usual there's patent pool licensing involved. This means that albeit XviD is open sourced it's not really free due to patent licensing issues. That's wrong – H.264 is MPEG4 Part 11 – it's part of the MPEG4 spec. Slight correction of myself, that should read: H.264 is MPEG4 Part 10. - Geoffrey Sneddon
Re: [whatwg] video element proposal
Le 3 mars 2007 à 20:29, Håkon Wium Lie a écrit : Finally, I think open formats are better than closed formats. The standards we write should not be neutral on this. Perhaps we should not name specific formats, however, only require that codecs are freely available for use across all platforms? Open formats by their nature give more freedom to developers and minimize economical constraints of implementation. As you said mandating a format gives the risk to make a specification completely irrelevant. Though even if we can update specifications, it doesn't mean that is that easy. It's what I usually call the consequences of the first times. When we define something which is largely deployed, it becomes very hard to fix depending on the ecosystem. It's exactly like biology. For the Web, if the number of *new* documents produced each year is… 10 times bigger than the *whole* legacy content of the previous years, then we can mandate things somehow. But if the number of *new* documents is only 10% of the legacy content, the renewal rate is not quick enough to make changes. Requiring a free codec could be seen as reasonable but could have consequences on the whole food chain too. Imagine that the specs require only Open source browsers, that would have the same effect. So what can we do? Maybe, something in between. It could be required that the implementations support at least a format which has one free codec. As it will encourage but not forbid. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool ***
Re: [whatwg] video element proposal
Le 3 mars 2007 à 21:58, Elliotte Harold a écrit : By the way, I checked. HTML 4.0.1 never actually defines image. It says imgs link to images, but it doesn't say anything about images being static that I noticed. How orthogonal are the specs really? There is a generic element in HTML 4.01 which has been designed specifically to be agnostic about the type of element you would like to insert. OBJECT element http://www.w3.org/TR/html401/struct/objects.html#edef-OBJECT Adding Multimedia in Web Documents (part 1) http://www.webstandards.org/learn/articles/askw3c/jun2004/ Adding Multimedia in Web Documents (part 2) http://www.webstandards.org/learn/articles/askw3c/may2005/ Some tests here http://esw.w3.org/topic/ObjectTestResults -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool ***
Re: [whatwg] video element proposal
Karl Dubost wrote: Why it is not necessary good to mandate a specific format in a specification * When to standardize, especially an RDF API Dan Connolly [1] http://www.w3.org/QA/2007/03/orthogonal_specifications_is_good That makes some sense, though reading it one thing jumps out at me. Why can we not link to a video with an img element? Why can't we link to a Flash animation or SVG or SMIL with an img element? Isn't a video just another image format? If the specifications really are orthogonal, then the media format shouldn't be relevant. By the way, I checked. HTML 4.0.1 never actually defines image. It says imgs link to images, but it doesn't say anything about images being static that I noticed. How orthogonal are the specs really? -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] video element proposal
On 3/3/07, Geoffrey Sneddon [EMAIL PROTECTED] wrote: On 1 Mar 2007, at 05:27, Shadow2531 wrote: On 2/28/07, Anne van Kesteren [EMAIL PROTECTED] wrote: Hi, Opera has some internal expiremental builds with an implementation of a video element. The element exposes a simple API (for the moment) much like the Audio() object: I think it'd be cool if the video element *just* supported theora. Why limit yourself to one format? So there's only one format to worry about implementing. So everyone using the element would be using the same format. However, as you said, there'll be better formats in the future, which is why I asked if it'd be better to require a base format be supported and then the vendor could support extra ones. However, the base format might be worthless in the future and it might be a burden to *have* to support it. With that said, if: 1. The spec makes no requirement on the format. 2. Vendors (at least the ones interested) agree to make their video element support one or more of the same base formats. 3. video src=base format/video is used as an example in the video element description in the spec (to suggest a format, kind of like the audio object suggests .wav) , what features do you want from the video element? loop, autostart, setPosition(), events, volume etc.? -- burnout426
Re: [whatwg] video element proposal
Shadow2531 wrote: With that said, if a browser can make its video element support as many formats as it wants (which I believe most people want), I do believe that its essential that there be a base format that must (or strongly should) be supported. That base format might be theora or something else. Or, do most feel the video element should just support whatever the browser wants and leave it at that? I think a base format is vital. With img we had de-facto standard formats because of what the first browsers supported. It took ages to get another one added (PNG) and it wasn't widely used until browser support firmed up. If a base format can't be guaranteed, people will just keep using Flash, which works almost everywhere (currently, with proprietary software only, but keep an eye on Gnash). Gerv
Re: [whatwg] video element proposal
On 2 Mar 2007, at 10:01, Gervase Markham wrote: I think a base format is vital. With img we had de-facto standard formats because of what the first browsers supported. It took ages to get another one added (PNG) and it wasn't widely used until browser support firmed up. If a base format can't be guaranteed, people will just keep using Flash, which works almost everywhere (currently, with proprietary software only, but keep an eye on Gnash). It may be a good idea to specify an either-or-both policy and include a second video format, allowing vendors a little freedom as to which to implement. Dirac (dirac.sf.net) seems like a good alternative format, but I don't know what licenses are acceptable to closed-source browser vendors. They say: As a defensive measure the BBC has applied for patent protection for some techniques that are, or may be, used within Dirac. Our purpose in doing so is to provide protection for Dirac from spurious patent suits by other parties. Under the terms of the MPL we have licensed these patents irrevocably and royalty free for use within the Dirac software. Our intention is that Dirac code be used as widely and as freely as possible. This is why we have allowed re-licensing under the terms of the GPL and LGPL licences. And on Theora: Theora is coming on very nicely, and has an impressive, well-defined spec. We think we have much better compression performance, but you can't have too many free codecs. We intend to pack the Dirac elementary stream into MXF, which has lots of useful features. That doesn't preclude it packing into Ogg (or Matroska, or anything else) as well, and it's probably a good idea to have a variety of packing formats. indeed! - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] video element proposal
Shadow2531 wrote: Or, do most feel the video element should just support whatever the browser wants and leave it at that? Personally I was unaware that there was a platform neutral, open, patent unencumbered video format. However if Theora is such a format, then that would be a very good thing; and I'm tempted to say we should introduce the video element and require it to support Theora and only Theora just to drive its adoption in place of all those annoying proprietary formats that never work right from one browser or PC to the next. But then I take a deep breath, and think that we're really not doing anything here that embed/object doesn't do. Video isn't all that different from Flash or SVG or other non-static embedded content. Different video formats will be used no matter what we do. I'm just not sure that I see a strong enough use case here to justify the introduction of another element most browsers will not support for years if ever. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] video element proposal
Nicholas Shanks wrote: It may be a good idea to specify an either-or-both policy and include a second video format, allowing vendors a little freedom as to which to implement. Either? But if one major browser implements one, and another implements the other, then you end up in the situation that having a restriction was supposed to avoid! Dirac (dirac.sf.net) seems like a good alternative format, but I don't know what licenses are acceptable to closed-source browser vendors. It's MPL/LGPL/GPL, just like the Mozilla codebase. MPL should be fine for closed-source vendors; GPL is OK for Konqueror. I wonder how complete the Dirac code is? I asked about Theora status in their IRC channel; MikeS said: There IS a decoder that I would say is suitable for widespread shipment. The mainline theora implementation has 3 major problems: 1) it doesn't implement 100% of the spec. 2) It's not 100% robust against invalid bitstreams; a maliciously crafted one could crash it. 3) it's not very fast. derf's theora-exp implementation has an encoder that doesn't work, but I assume that's irrelevent for a browser. The _decoder_ fixes all three of those major issues. we haven't done a formal release of that decoder, but it's in a releasable state - if someone was seriously interested in giving it widespread use we'd do the work to release it. They think you could get ogg + theora + vorbis decoders into 130k compressed, without too much difficulty. Gerv
Re: [whatwg] video element proposal
Elliotte Harold wrote: I'm just not sure that I see a strong enough use case here to justify the introduction of another element most browsers will not support for years if ever. I think there's a strong driver for uptake. As I understand it, all these video-sharing sites are paying mountains of cash to Adobe/Macromedia for the backend software licences to support Flash video streaming. If they could have 15 or 20% fewer servers doing that, and stream to Firefox using Theora instead, the cost saving would be an incentive for them to change their site. Particularly if we implemented video in a way which gave them all the capabilities the flash player has - e.g. fast forward, rewind, seek etc. Of course, I don't know how those costs compare to the bandwidth bill. Gerv
Re: [whatwg] video element proposal
Gervase Markham wrote: There IS a decoder that I would say is suitable for widespread shipment. The mainline theora implementation has 3 major problems: 1) it doesn't implement 100% of the spec. 2) It's not 100% robust against invalid bitstreams; a maliciously crafted one could crash it. 3) it's not very fast. derf's theora-exp implementation has an encoder that doesn't work, but I assume that's irrelevent for a browser. The _decoder_ fixes all three of those major issues. we haven't done a formal release of that decoder, but it's in a releasable state - if someone was seriously interested in giving it widespread use we'd do the work to release it. The real key is the format. not the decoder. If the format is well-documented, open, non-proprietary, and high enough quality for the web (for several definitions of quality) then browser vendors can write their own decoders, as open or closed source. It's nice if there's an existing decoder they can just adopt, but it's by no means necessary, especially for closed source vendors with the resources of Microsoft or Apple. The real question is whether such vendors would add support for such an open format that competes directly with their own proprietary formats. I suspect the answer is no, but I hope I'm wrong about that. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] video element proposal
Gervase Markham wrote: I think there's a strong driver for uptake. As I understand it, all these video-sharing sites are paying mountains of cash to Adobe/Macromedia for the backend software licences to support Flash video streaming. If they could have 15 or 20% fewer servers doing that, and stream to Firefox using Theora instead, the cost saving would be an incentive for them to change their site. Particularly if we implemented video in a way which gave them all the capabilities the flash player has - e.g. fast forward, rewind, seek etc. But there's one capability of Flash I don't want to give them: the ability to block users from easily downloading, editing, and reusing the content. You may be right, and I hope you are, but I suspect content hording may be important enough to them to justify the extra 15% or 20% cost. OTOH, this might enable lower cost, less hordeful competitors, That would be nice. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] video element proposal
Gervase Markham wrote: Elliotte Harold wrote: I'm just not sure that I see a strong enough use case here to justify the introduction of another element most browsers will not support for years if ever. I think there's a strong driver for uptake. As I understand it, all these video-sharing sites are paying mountains of cash to Adobe/Macromedia for the backend software licences to support Flash video streaming. If they could have 15 or 20% fewer servers doing that, and stream to Firefox using Theora instead, the cost saving would be an incentive for them to change their site. I believe the fact that the format is open and patent free is also a good driver. I am thinking about sites like wikipedia here. They are already good ambassadors for SVG and Theora ( http://en.wikipedia.org/wiki/Wikipedia:Image_Use_Policy#Format ) And there is actually Theora content out there in the wild! ( http://en.wikipedia.org/wiki/Apollo_15 ) And it seems like the wikipedians are looking for technical solutions to play sounds and movie clips in their articles ( http://meta.wikimedia.org/wiki/Multimedia#Software_features ) We need to be 100% sure that the format is patent free (no more GIF). I could have one concern about the Theora licensing. I am not sure what this 'promise' not to enforce patents is worth legally ( http://www.theora.org/svn.html ). The statement is for example very focused on the on2 company. What happens if they go bankrupt or decide sell their patents? Open source licensed patents like BBC/Dirac would let me sleep a bit better i think. Especially since on2 is also behind the decoder for flash movies ( http://www.on2.com/ ) - this could possibly lead to conflicts of interests and nastiness. Like some previous posters I also think that only a few formats (or even just one) should be supported by the video tag. I specifically think that we should let the proprietary formats live on in the object world. But it may be difficult to prevent proprietary formats to slip over to video. /Magnus
Re: [whatwg] video element proposal
Le 1 mars 2007 à 14:27, Shadow2531 a écrit : On 2/28/07, Anne van Kesteren [EMAIL PROTECTED] wrote: Hi, Opera has some internal expiremental builds with an implementation of a video element. The element exposes a simple API (for the moment) much like the Audio() object: I think it'd be cool if the video element *just* supported theora. Why it is not necessary good to mandate a specific format in a specification * When to standardize, especially an RDF API Dan Connolly [1] http://www.w3.org/QA/2007/03/orthogonal_specifications_is_good -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool ***
Re: [whatwg] video element proposal
On 3/1/07, Lachlan Hunt [EMAIL PROTECTED] wrote: Shadow2531 wrote: On 2/28/07, Anne van Kesteren [EMAIL PROTECTED] wrote: Opera has some internal expiremental builds with an implementation of a video element. The element exposes a simple API (for the moment) much like the Audio() object: I think it'd be cool if the video element *just* supported theora. Mandating support for a single specific video format like Theora would be like requiring browsers to only support PNG for images. As Martin said, Perhaps ogg can be the format required to conform. Then other types can be supported through whatever means (native or mapping to a plugin like wmp etc.) If it supports whatever the browser wants to implement, we'd have to do like the following I think. video src=test.wmv video src=test.mpg video src=test.ogg I give up /video /video /video Or simply use video src=testembed src=test!-- fallback --/video Yes, that also. And use server-side content negotiation to determine the best one to send. The browser could send along the list of supported MIME types in it's accept header for video formats, like: Accept: application/ogg, video/mpeg, video/mp4, application/mp4, video/quicktime, */*;q=0.1 Sounds good. -- burnout426
Re: [whatwg] video element proposal
On Thu, 01 Mar 2007 06:27:45 +0100, Shadow2531 [EMAIL PROTECTED] wrote: Opera has some internal expiremental builds with an implementation of a video element. The element exposes a simple API (for the moment) much like the Audio() object: I think it'd be cool if the video element *just* supported theora. It probably doesn't make much sense to impose such restrictions. If it supports whatever the browser wants to implement, we'd have to do like the following I think. video src=test.wmv video src=test.mpg video src=test.ogg I give up /video /video /video The intentention of the draft is that this is allowed. It might not be specified entirely correct though. Hence the proposal status :-) You probably want the video element to be really, really basic, but I don't think it should be. It needs to have some features (eventually). These are just some of the things *I* might like. [...] That's one of the reasons a dedicated element is better than reusing the object element. All the new video specific APIs would otherwise have to be defined for all possible things the object element can represent (images, nested browser context, video, audio, plugins, etc.). Given that the object element is already a nightmare for implementors... I assume you want the width and height attributes to be used only for specifying the original width and height the video was made at, and css should be used to set the width and height to a % or px etc.? Yeah, maybe. I was thinking about something along those lines, but I couldn't really figure out how it would work. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] video element proposal
On Mar 1, 2007, at 08:26, Lachlan Hunt wrote: The browser could send along the list of supported MIME types in it's accept header for video formats, like: Accept: application/ogg, video/mpeg, video/mp4, application/mp4, video/quicktime, */*;q=0.1 Content negotiation is like a box of chocolates. You never know what you are going to GET. :-) The problem in this case is that the media types map roughly to the container formats. However, the codecs are what really count. For example, MPEG-4 Simple Profile, MPEG-4 Advanced Simple Profile and H. 264 all live in the video/mp4 container. However, support for these codecs and their zillion subprofiles varies. (Yet another example why optional profiles in spec are bad for interop. The profiling of the MPEG-4 video stuff is worse than any Web spec Mobile Profile.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] video element proposal
Anne van Kesteren wrote: I'm not sure what fallback has to do with interoperability. Fallback allows text mode browsers or video plugins that do not support a given codec to access the essential information. Hence it makes for a form of communication interoperable with a wide range of devices. (i.e. it doesn't make the video interoperable, it makes the website interoperable.) It doesn't seem wise to mandate a particular UI. Sorry, I've obviously been unclear. I don't mean tell UAs what UI to use, I mean tell them what minimal functionality to expose (e.g. UAs should allow users to pause video.). /How/ they do that (play button, mouse gestures, telepathy, etc.) should be up to them entirely (subject to UAAG considerations of course). User agents are free of course to expose the functionality of play(), pause() and stop() in some way, in my opinion. Isn't it important that content authors know whether there will or won't be an automatic UI provided, so that end users don't end up being presented with two (possibly conflicting, certainly confusing) UIs? That's why I suggested using an attribute to control For most use-cases, I suspect the minimum functionality would not only be more than enough, but superior than anything the content producer would put together. This would actually make it a lot easier for ordinary HTML authors to put video on the web. If we could mandate captioning and audio description exposure by UAs it would make putting video on the web in an accessible manner much easier too. Which would be great, as it currently seems to be a somewhat complicated task. -- Benjamin Hawkes-Lewis -- Benjamin Hawkes-Lewis
Re: [whatwg] video element proposal
Also sprach Bjoern Hoehrmann: Opera has some internal expiremental builds with an implementation of a video element. The element exposes a simple API (for the moment) much like the Audio() object: play() pause() stop() May I suggest Opera does not implement features that are incompatible with SMIL, the SMIL implementation in Internet Explorer, and SVG for no extraordinarily good reason? I think we want to make video a first class citizen of the web. That means, IMHO, that there must be a simple way to add video to HTML pages. I don't think one shoulr rely on other languages for this, although I'm perfectly happy supporting those other languages as well. Part of the reason why we could to this so quickly is the work we have done on SVG. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] video element proposal
Also sprach Shadow2531: I think it'd be cool if the video element *just* supported theora. It's an interesting proposal. Traditionally, HTML/CSS hasn't said anything about which image/icon formats to support. Given, however, that (a) our ultimate goal is interoperability and that (b) many video formats are impossible to support on all devices (mostly due to legal issue), I think we should consider your proposal. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] video element proposal
On 1 Mar 2007, at 11:56, Anne van Kesteren wrote: That's one of the reasons a dedicated element is better than reusing the object element. All the new video specific APIs would otherwise have to be defined for all possible things the object element can represent (images, nested browser context, video, audio, plugins, etc.). Given that the object element is already a nightmare for implementors... Would I be right in thinking of video as inheriting from/a subclass of object then, to draw an OOP analogy. Or would they be more like siblings? Secondly, I think of ‘video’ as a sequence of visual frames with no audio. I presume you mean something more akin to what I call a movie container, with a video track, multiple audio dubbing tracks in different languages, subtitles or graphical overlays, c. If so, do you think the name could be altered to reflect this? Thirdly, are you intending for there to be audio counterpart? I assume you want the width and height attributes to be used only for specifying the original width and height the video was made at, and css should be used to set the width and height to a % or px etc.? Yeah, maybe. I was thinking about something along those lines, but I couldn't really figure out how it would work. Video streams/files already contain their native pixel dimensions, and as Henri said, you never know what you're going to GET. A better attribute would be scale which takes a floating point value, defaulting to 1.0 (should probably have a corresponding CSS element too, which we could apply to other things that have native dimensions like still images). This would work well with max-/min-width. You may want to consider aspect ratio too: ratio=preserve being default, ratio=1.333 could indicate 4:3 or get tricky and accept 16:9 for precision reasons. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] video element proposal
Håkon Wium Lie wrote: I think we want to make video a first class citizen of the web. Arguably it already is. It just hasn't been implemented in a easy-to-author, UA-interoperable, or end-user accessible fashion. That means, IMHO, that there must be a simple way to add video to HTML pages. How is that incompatible with the use of SMIL? It seems to me adding video to web pages is complicated because of: 1) Poor support for a wide variety of formats. 2) No guaranteed end-user capability to play, pause, rewind, etc. (so that authors must build such interfaces themselves with JS). 3) Lack of guidance for transcripting/subtitling/captioning/audio description (Joe Clark's working in this area) and poor implementations of technology for such features. 4) Different browsers support different techniques for embedding content in text/html (e.g. embed vs object, ActiveX for MIME handling, the Eolas problems in IE). As it stands, the video element proposal is interesting, but it doesn't solve any of these problems for current or future UAs. If we require HTML5 UAs to support Theora and to expose a minimal subset of functionality, then we could conceivably fix 1) and 2) over the next few years (IE/WMP being the major barriers here). Whether we can fix 4) seems to be partly dependent on American courts. Mandating support for SMIL should help with 3). It may be mandating support for Ogg would also help, but there seems to be some doubt (e.g. from a BBC researcher) as to whether Ogg is really suitable for multiple audio video streams in the same file for things like audio description and multi-language subtitles, and alternate audio tracks: http://lists.xiph.org/pipermail/xiph-rtp/2007-January/000461.html I don't think one shoulr rely on other languages for this, In reality, aren't you always relying on a language /of some sort/ (e.g. a wrapper language for video)? It's not like you're trying to express the video data within HTML. Part of the reason why we could to this so quickly is the work we have done on SVG. IANAL and don't know Opera's licencing policy anyway, but if it makes any difference there is a SMIL 2.1 player whose source code is available for use by third parties under the LGPL: http://www.cwi.nl/projects/Ambulant/FAQ.html -- Benjamin Hawkes-Lewis
Re: [whatwg] video element proposal
Anne van Kesteren [EMAIL PROTECTED] wrote: Opera has some internal expiremental builds with an implementation of a video element. I've observed widespread frustration amongst authors on how to offer audio and/or video on web pages. Quite a few have started using Flash since apparently it takes some of the pain out of doing so. That seems to warrant looking at a solution that doesn't use a proprietary technology like Flash. When the src= attribute is set, the user agent must immediately begin to download the specified resource, unless the user agent cannot support videos, or its support for videos has been disabled. As soon as enough data is received the user agent should start decoding the video. This means that play() and other methods can already be used before the resource is downloaded completely. I strongly dislike audio and/or video that automatically downloads and starts playing automatically, so much so that I've disabled media player plugins altogether. Both audio and video files are often considerable in size. I don't want my web browser to start making noise unless I've explicitly chosen to play audio, this should not be the result of simply loading a web page. I'd favour a spec requirement that a UA must offer users a configuration option not to automatically download and start audio and/or video and let the user decide first. Another current common frustration amongst authors is how to get file based media files to play before they've been fully downloaded. This is currently achieved by using text based redirector files containing the url to the actual media file, but these redirector formats have only been defined for a limited number of media formats. That would suggest that a UA could by default employ progressive downloading. Issue: should we very much like the img element just ignore 404 errors and the Content-Type header? And use the file extension or content sniffing? Using file extensions doesn't seem possible given the existence of wrapper formats. I imagine that a browser that can handle JPEG, PNG and GIF can use content sniffing and depending on the outcome feed it to the right decoder. I'm having difficulty imagining how that would work with video. Wouldn't that require a UA to at least be able to open the file headers of the many video file formats out there to sniff what media format is actually inside them before it can decide where to send the data? Issue: height / width Currently an issue with supplying height and width for video content embedded with the object element is that the supplied width and height includes the chrome and UI controls of the embedded player. That creates problems for authors who often don't know the size of those elements in advance, it may depend on the player and/or player skin they use. Scaling video can be very GPU intensive, so it would be helpful if there was a way to ensure that video can play in it's native size, whilst at the same time knowing in advance what room to reserve in the flow for the media and any player chrome. -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] video element proposal
Spartanicus wrote: Another current common frustration amongst authors is how to get file based media files to play before they've been fully downloaded. This is currently achieved by using text based redirector files containing the url to the actual media file, but these redirector formats have only been defined for a limited number of media formats. That would suggest that a UA could by default employ progressive downloading. I was thinking about this the other day. There seems to be no way of distinguishing the case where you want to hand the data from a URL to an external program (e.g. Word files), and you want to hand the URL itself to an external program (e.g. streaming audio). Not sure if a solution to this is in scope for WHAT-WG... Currently an issue with supplying height and width for video content embedded with the object element is that the supplied width and height includes the chrome and UI controls of the embedded player. That creates problems for authors who often don't know the size of those elements in advance, it may depend on the player and/or player skin they use. Scaling video can be very GPU intensive, so it would be helpful if there was a way to ensure that video can play in it's native size, whilst at the same time knowing in advance what room to reserve in the flow for the media and any player chrome. That's the equivalent of: yvideo + ygui = ytotal where yvideo is defined in advance by the video file, and ytotal needs to be known in advance. The only way that's possible is for ygui to be fixed across all platforms etc. Gerv
Re: [whatwg] video element proposal
On 3/1/07, Håkon Wium Lie [EMAIL PROTECTED] wrote: Also sprach Shadow2531: I think it'd be cool if the video element *just* supported theora. It's an interesting proposal. Traditionally, HTML/CSS hasn't said anything about which image/icon formats to support. Given, however, that (a) our ultimate goal is interoperability and that (b) many video formats are impossible to support on all devices (mostly due to legal issue), I think we should consider your proposal. Yes, those are the main reasons for my suggestion. I realize that just supporting one format like theora for example means that a lot of the current content out there couldn't be handled by the video element. However, the video element would be new and with it new content. It doesn't necessarily need to be compatible with everything (as it'd be a new element). I don't think the video element can replace OBJECT and its wide (but messy) handling of different things. I think VIDEO should be specific and avoid all or most of the problems object has. As you said, it'd be untraditional, but if the format is not specified, I can see one browser's video element only supporting mpeg and another only supporting wmv and another only supporting ogg and other only support .flv etc. With that said, if a browser can make its video element support as many formats as it wants (which I believe most people want), I do believe that its essential that there be a base format that must (or strongly should) be supported. That base format might be theora or something else. Or, do most feel the video element should just support whatever the browser wants and leave it at that? -- burnout426
Re: [whatwg] video element proposal
* Anne van Kesteren wrote: Opera has some internal expiremental builds with an implementation of a video element. The element exposes a simple API (for the moment) much like the Audio() object: play() pause() stop() May I suggest Opera does not implement features that are incompatible with SMIL, the SMIL implementation in Internet Explorer, and SVG for no extraordinarily good reason? -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] video element proposal
Anne van Kesteren wrote: Opera has some internal expiremental builds with an implementation of a video element. The element exposes a simple API (for the moment) much like the Audio() object: play() pause() stop() Were any sort of fast-forward or rewind functions considered? Gerv
Re: [whatwg] video element proposal
Opera has some internal expiremental builds with an implementation of a video element. The element exposes a simple API (for the moment) much like the Audio() object: play() pause() stop() Can't such an API be provided for object elements that reference video? The idea is that it works like object except that it has special video semantics much like img has image semantics. What are those semantics? Would interactivity be disabled, like Mozilla is planning to do for SVG in img elements? If [...] the resource is not a supported video format [...] the user agent must fire an error event on the video element and if it was still downloading it must abort that process. What is considered a video format? Would Flash or SVG be allowed?
Re: [whatwg] video element proposal
On 2/28/07, Anne van Kesteren [EMAIL PROTECTED] wrote:
Hi,
Opera has some internal expiremental builds with an implementation of a
video element. The element exposes a simple API (for the moment) much
like the Audio() object:
I think it'd be cool if the video element *just* supported theora.
If it supports whatever the browser wants to implement, we'd have to
do like the following I think.
video src=test.wmv
video src=test.mpg
video src=test.ogg
I give up
/video
/video
/video
You probably want the video element to be really, really basic, but I
don't think it should be. It needs to have some features (eventually).
These are just some of the things *I* might like.
Events should be supported on the element (even on the video area):
document.getElementsByTagName(video)[0].addEventListener(click,
function(e) {
e.target.pause();
}, false);
onbuffering, onplaystatechange, onvolumechange (maybe),
onpositionchange, ondownloadcomplete etc. (also via addEventListener)
Some methods|properties:
.getPlayState(), .getVideoWidth() (original size the video was made
at), .getVideoHeight()(original size the video was made at),
.getFileSize(), .getPos(), .setPos()
.volume, .loop, .startpos, .autostart, .allowseek
params (default first):
volume = 50 | 0 - 100
allowseek = true | false
loop = false | true
autostart = true | false
startpos = 0 | specified pos
(how useful is a playcount param? I myself either want it to play once
or forever and not in between.)
video {width: 100%; height: 100%;} should make the video element (and
of course the video itself along with it) autoresize with its
surroundings like an img would.
Changing style.width for example would adjust the video element's (and
of course the video's) width without disrupting playback.
Getting carried away, but I also would like the video element to
support xspf playlists that specify URIs to ogg files.
http://www.xspf.org/quickstart/. In that case, an onvideochange
event may be in order and a VideoElement.playlistDoc could be used to
reference the playlist tree. (If for example, you wanted to grab data
out of the xml playlist.)
I assume you want the width and height attributes to be used only for
specifying the original width and height the video was made at, and
css should be used to set the width and height to a % or px etc.?
--
burnout426
