Re: [whatwg] More YouTube response
Hardly an expert in this field, but wouldn't implementing media tags (video and audio) a tad like websockets be a good idea. Using the tag should add a special header that says it can upgrade conneciton to something like media which constantly lets client have duplex conversation with the server, which can give all sorts of information about the client side like desired bitrate, desired camera, player state(pause, resume,etc) which will have reasonable default behaviour, but can be set or taken over by javascript if needed. On the other hand, if the server end was not happy with the upgrade request, the browser cann fall back to current behaviour just my two cents -- Laxminarayan Kamath Ammembal http://lankerisms.blogspot.com (+91) 9945036093
Re: [whatwg] More YouTube response
This is a bulk reply to the feedback that resulted from the following blog post from YouTube's API team: http://apiblog.youtube.com/2010/06/flash-and-html5-tag.html On Wed, 30 Jun 2010, Tab Atkins Jr. wrote: So, for a quick recap, their problems are: 1. Standard video format 2. Robust video streaming 3. Content Protection 4. Encapsulation + embedding 5. Fullscreen video 6. Camera and Microphone access The blog itself successfully covers the current responses to 1, 2, 5, and 6. #3 is a different story; it doesn't appear that anyone in this space is working on that or intends to. And I'm happy with that. #4 is kind of silly - flash embedding doesn't protect anyone's private data - the plugin can do plenty of malicious stuff if it wants to. Spreading videos by embedding script tags would be equally safe. I think people just don't realize that fact. In any case, embedding videos via [iframe should work fine] Indeed. To reiterate for the record: 1. Standard video format This is up to browser vendors; we have several options. The market will likely end up resolving this. 2. Robust video streaming This is at the stage where we should get browser implementation experience. 3. Content Protection Fingerprinting is already possible; DRM is mathematically impossible. See below for slightly more on this, but this was covered in depth in the threads so I won't add much. 4. Encapsulation + embedding Should be possible with existing technologies (a number of people discussed this on these threads so I won't reiterate further here). 5. Fullscreen video See recent threads; this will likely be solved in due course via CSSOM extensions. 6. Camera and Microphone access This is in early stages, but see the device element for ideas here. It's currently stalled waiting for people to volunteer to work on protocol-side work. On Wed, 30 Jun 2010, Marques Johansson wrote: What is the problem with #3? My recent emails on this list concern #3. I know that anything that has been seen or heard can be recorded, replayed, and redistributed by illegitimate parties but that doesn't mean content protection is silly. Content protection is silly because it is impossible to simultaneously prevent someone from accessing data, and allow someone to access it. It's _especially_ silly in an open standard implemented by open source software, since you can't even rely on the usual obfuscation technique. (I haven't responded to any other e-mails on these threads regarding DRM, since none got beyond this problem.) For pay-per-video services I would think a watermark + sue policy for files distributed over HTML5/HTTP could handle content protection as well as any flash based solution. Sure, that's already possible. For pay-per-minute or pay-per-byte services I believe the HTTP and/or HTML5 specification needs some minor changes to allow the server to dictate the amount of data the UA should attempt to fetch from an open and standard file over an open and standard protocol. Why can't the server control this already? On Wed, 30 Jun 2010, Marques Johansson wrote: The problem with throttling alone (yes, the server would be throttling as well) is that when a user seeks to some point in the video the UA request will look like Range: bytes 0- or Range: bytes 1500-. The server is then expected to keep this connection open (idling or trickling data) while the user takes a break and plays 5 seconds or 5 minutes of video. There is definitely room for more advanced protocols than just straight HTTP for media streaming. This is an area where we should start with browser experimentation. On Thu, 1 Jul 2010, Kevin Carle wrote: One part of (2) [well, debatably part, but related to video streaming] is the lack of visibility into stream behavior. I can't ask the video element questions about dropped frames, bitrate, etc. This is incredibly useful in Flash for getting streaming feedback, and means I really don't know how well the HTML5 player is working for users. The best I can do is waiting/stalled events which is nowhere near as granular. Exposing this information is one of the features queued up for the next version (after we get the subtitles stuff sorted out). You can see the current list of such feedback here: http://www.whatwg.org/issues/#video--new-features-awaiting-stable-implementations -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] More YouTube response
On Wed, Jul 7, 2010 at 4:54 PM, John Harding jhard...@google.com wrote: MySpace is my canonical example - they allow arbitrary SWFs to be embedded in profiles, but not iframes. Flash added support a while back that allows containing pages to block SWFs from executing script or accessing the contents of the page, which MySpace enforces by rewriting the embed tag that users post. Before that, yes, allowing arbitrary SWFs to be posted by users was a huge security hole. Interesting. I wonder what the rationale was behind banning iframe. Regardless, I think we're all agreed on the path forward (Use iframes to embed content instead of naked embed tags) and just need to start moving on it, and the ball is largely in YouTube's court on this point. Great to hear you see it that way.
Re: [whatwg] More YouTube response
On Tue, 06 Jul 2010 23:19:42 +0200, Marques Johansson marq...@displague.com wrote: On Tue, Jul 6, 2010 at 4:37 PM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: On Tue, Jul 6, 2010 at 10:24 AM, Marques Johansson marq...@displague.com wrote: The benefit to the user is that they could have less open network connections while streaming video from server controlled sites and those sites will have the ability to meter their usage more accurately. Inserting an extra clip at the end is more of a playlist or scripting answer. Or perhaps a a live re-encoding answer. I'm looking for a way to give the user the raw video file in a metered way. It sounds like your use-case is very special, and best handled by script. I suggested server-side script -- you could do that today. Just cut off the HTTP connection when the user has used up their allotted time. Alternatively, it might be reasonable to have client-side scripting for video that's flexible enough to do what you want. But a dedicated declarative feature is just not reasonable for such a specific purpose. I tested cutting off the HTTP connection and browsers didn't handle this. I realize I may need to test a deeper sever than a php exit() can provide. I have essentially tested this (but not this exactly - filehandles, sessions, additional code, etc): ?php header(HTTP/1.1 206 partial); header(Accept-Ranges: bytes); header(Content-Range: bytes 0-99/100); header(Content-Length: 100); // report 1000k echo str_repeat( , 1000); // return 1k exit(); and found that browsers do not attempt to refetch the data or continue with a 206 for the next block. Shouldn't something like this be be worked into the protocol or the language One thing that you mustn't lie about is Content-Length, so I assume that the real size of this resource if 1000k. If you're trying to return a too short range, you should say so in the Content-Range header. In other words, in the above you should have used header(Content-Range: bytes 0-999/100); I'm not sure it will work anyway, though. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] More YouTube response
On Tue, 06 Jul 2010 17:42:22 +0200, Marques Johansson marq...@displague.com wrote: On Tue, Jul 6, 2010 at 10:59 AM, Philip Jägenstedt phil...@opera.comwrote: On Tue, 06 Jul 2010 16:24:45 +0200, Marques Johansson marq...@displague.com wrote: Some UAs request video without sending Range: bytes 0-. The server has no way to negotiate that the UA (a) must use ranges to complete the request or that (b) the range requested is too large, retry will a smaller range. The first request is tricky for the browser too. Having no idea of how big the resource is or what the bitrate is, there is no bounded request that makes sense, in my opinion. The downside is that for a conservative approach, the only solution is to abort the connection half way through, with the server having no idea when this will happen. I haven't seen any negative effects of this in practice yet, but this thread has me thinking that it could be better. Handling a short reply gracefully would be a good start. For webm files, Chrome requests 0-1024 and then some block near the end of the file. I assume that the meta data / time ranges are stored at these locations. As for bounded requests that make sense - I'm sure the server hosting the content could suggest something ;-) If the index is stored in the beginning of the file, there should be no need to seek to the end. What we want is to get at least metadata and the first frame in a single request, and I can't guess any number that doesn't risk being larger than the file itself. Somehow involving the server just amounts to two network roundtrips, which was exactly what we were trying to avoid. I've tried having the server disconnect a HTTP/1.1 200 response by doing a php exit() before having sent the Content-Length specified number of bytes. Browsers did not attempt to pick up where the server left off. I think you are suggesting that the client disconnect but without scripting I don't really have control over that and if with scripting that doesn't seem doable unless the video element could be feed with an appendBytes() type of function. Yes, the browser disconnects, and scripts have no influence over it. With preload=metadata implemented, it should disconnect as soon as possible after getting enough data for the first frame. For preload=auto, it will disconnect after buffering X seconds of data. If you need more granularity than that, I suggest server-side control informed by information collected by JavaScript. If browsers handled a short reply to a range request, it should work just fine, no? -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] More YouTube response
Could not agree more Anne -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Anne van Kesteren Sent: Friday, July 02, 2010 1:38 PM To: Henri Sivonen; Shane Fagan Cc: Andy Berkheimer; John Harding; wha...@whatwg.org Subject: Re: [whatwg] More YouTube response On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Well this isnt really a list where we should talk about the dos and donts of web content distribution. DRM content can be embedded in the video tag and decoded using installable plugins so its not really an issue for this list I dont think. We cant dictate how the specs are used so try to keep the conversation technology neutral. Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have video in the first place. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] More YouTube response
Yes, the browser disconnects, and scripts have no influence over it. With preload=metadata implemented, it should disconnect as soon as possible after getting enough data for the first frame. For preload=auto, it will disconnect after buffering X seconds of data. If you need more granularity than that, I suggest server-side control informed by information collected by JavaScript. If browsers handled a short reply to a range request, it should work just fine, no? Yes. I started my quest as a Firefox bug report https://bugzilla.mozilla.org/show_bug.cgi?id=570755 .. The developers weren't sure that the HTTP spec actually permits a browser to handle a short response in this way. When I went fishing around through the spec I found some things that seemed to permit this and other things that contradicted them (noted in the bug report). I started mailing the HTTP-bis group but they were not convinced either http://lists.w3.org/Archives/Public/ietf-http-wg/2010AprJun/0339.html. Chrome handles short 206s the same way Opera's ogg handler does but nothing else does.
Re: [whatwg] More YouTube response
MySpace is my canonical example - they allow arbitrary SWFs to be embedded in profiles, but not iframes. Flash added support a while back that allows containing pages to block SWFs from executing script or accessing the contents of the page, which MySpace enforces by rewriting the embed tag that users post. Before that, yes, allowing arbitrary SWFs to be posted by users was a huge security hole. Regardless, I think we're all agreed on the path forward (Use iframes to embed content instead of naked embed tags) and just need to start moving on it, and the ball is largely in YouTube's court on this point. -John On Fri, Jul 2, 2010 at 6:20 PM, Maciej Stachowiak m...@apple.com wrote: On Jul 2, 2010, at 6:04 PM, Maciej Stachowiak wrote: Any site which does that has a giant security hole, since Flash can be used to arbitrarily script the embedding page. It's about as safe as allowing embedding of arbitrary off-site script. If you are aware of sites that allow embedding of arbitrary off-site Flash, you should alert them to the potential security risks. For example a social network site that allowed this would be vulnerable to a self-propagating worm. What I have heard before is that sites whitelist specific SWFs or Flash from specific domains. I'm don't have any first-hand knowledge of how sites actually do it. With testing I found at least one site where I can apparently embed arbitrary SWFs. However, this site has per-user domains, so it might be relatively safe. This site also allows me to embed arbitrary content in an iframe. Regards, Maciej
Re: [whatwg] More YouTube response
Ok - sounds like pretty much unanimous objection to the idea of DRM plugins being instantiated via video tag. I'll still be pushing on the DRM plugin providers to implement an interface that mimics the video tag - my primary goal is to be able to have a single player implementation independent of whether or not DRM is involved. It's not the end of the world if one uses video and the other uses embed. -John On Mon, Jul 5, 2010 at 8:45 AM, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: John Harding jhard...@google.com schrieb am Thu, 1 Jul 2010 15:59:37 -0700: 1. Standard Video Format […] On the current path, a content provider knows that by offering H.264 and WebM, they can reach all HTML5-capable browsers. This honestly is a reasonable state for YouTube right now - we use H.264 in cases outside the video tag as well, but it would be nice to converge on a single baseline format at some point in the future. Practically, I think the ball is / was in Apple's court to decide this. While to this day other browser makers have decided to ship two (!) royalty-free video formats (Theora and VP8), Apple is the single H.264 holdout, and they have a tight itegration to their hardware as well. Sadly, I do not have hope for any consolidation regarding video formats. And while Youtube may be fine with having to provide only two formats instead of a dozen, for the common smaller webmaster this is a significant task, as transcoding resources are limited. Recently, I have been discussing video implementation with the administrator of an imageboard. It was ultimately decided to not add this feature, precisely because of the multitude of video formats of which none can be played in every modern browser. It's a shame. […] 3. Content Protection […] The basic requirements around content protection that we get from content owners basically consist of encrypting the content and limiting the decryption to a verified and authorized client - the realm of traditional DRM. This can not possibly work if you have an open standard, which by design has to be implementable by everyone who cares, which includes a wide range of free and proprietary software vendors. Rather than ask browsers to get into the DRM business, what I think would work best is having a means for 3rd party DRM providers to supply browser plug-ins which implement the video tag for protected content - not all that different than selecting a pluggable codec. To define a feature like that would hurt an otherwise open standard and help to balkanize the browser market even more. If you really want to do this, why not just use flash / java / whatever can deliver using already available proprietary means ? […] Greetings, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] More YouTube response
On Mon, Jul 5, 2010 at 10:25 PM, Henri Sivonen hsivo...@iki.fi wrote: On Jul 5, 2010, at 13:10, Marques Johansson wrote: For the content that is not protected the download or stream is metered so the client can be charged only for the time they spent watching the content. We error on the customer's side for things like buffering and misreported play segments. There'd be no problem if you were selling content by title (plus free trailer for sampling) instead of selling it by minute. If a user is paying for bandwidth why should they need to pay for a download of the full movie when they are only interested in a few scenes or a few key seconds of the video. A friend of mine called this weekend to confirm that a scene in Back to the Future 3 that has been popping up online was actually in the movie and not just some Internet hoax. He called to have me watch a particular segment on the DVD. I watched all of 3 minutes of the movie to confirm the original scene contents. Doc Brown's young blond haired train companion (who only appears at the end of the movie) displays a very preverse set of gestures in his 10 seconds of screen time that should have been edited out (I dodged all spoilers). There is a market for this kind of viewing habit that does not insist on the consumer purchasing a full right/license to the entire video nor the bandwidth or storage to accommodate it. When you are selling adult content - many users are much happier to pay for a few minutes of content that they seek through rather than a full movie that they will have little interest in watching again. The difference can easily be $.16 versus $16. As for trailers, many of our plans include additional time and all users that have ever purchased get 3 free 30 second plays weekly. That being said, I don't think the business models of one of the largest online video markets should put be on trial through a by a standards list. I think the discussion that DRM is irrelevant has its merits, but the contracts and services at play have a real value regardless of how distribution is restricted. I think the technology providers shouldn't feel an obligation to cater to particular contract models--especially when it complicates the technology. It makes more sense to draft contracts that are reasonable given the technology. (An example of a contract that I think technology providers shouldn't attempt to cater for is a content licensing contract that tries to distinguish between desktops, mobile devices and TVs. Such a contract makes no sense when devices of any kind can support the same standards.) I think providers cater to the technology that's available. At the time these contracts were drawn up Windows Media player and Real were leading the streaming video market. The contracts and services in place now were created pre-Youtube, when most users accessed the site with a 56 modem or less. The service was geared toward online streaming and streaming rentals rather than downloads - which could take some users days to complete - or longer when coupled with bad re-try behaviors in browsers. Cell phones couldn't play let alone download a video over their 14kbps connection. For my purposes I am interested in application-controlled video delivery. I want to be able to deliver unprotected mp4, webm, or ogv content in a metered way. If the user has payed to watch the entire video once and has managed to work around HTTP no-cache and the other constraints that a normal browser viewed experience would have, then they will have succeeding in downloading a copy of the video - a task which they could have accomplished with a VM session or through other means regardless of DRM. If the customers pay for seeing an entire title, why is it a problem if a customer once in a while downloads the bytes twice? Surely it is simpler to bake the average bandwidth cost into the price and not complicate the way the delivery technology behaves. We have different plans available. Some allow a user to stream a chosen video as often as they want. There are plans that allow users to stream an entire studios selection of videos on demand. This likens the service to a monthly membership site and the company I work for has found that many users prefer to not have that sort of commitment - preferring instead to pay for what they watch when they watch it. The choice is determined by the content provider and the user - we accomodate both parties to the best of our ability. These requests can be seen as generally allowing servers to reduce load for video or large file downloads. Since a client may be able to download 5 minutes of video in under a minute I would like to see the client disconnect from the server and reconnect in 5 minutes to get the additional content. Wouldn't this be a non-problem if the customers paid by title? In that case, it would seem pointless to worry about the content getting downloaded faster
Re: [whatwg] More YouTube response
On Mon, Jul 5, 2010 at 7:53 PM, Bjartur Thorlacius svartma...@gmail.comwrote: On Mon, 5 Jul 2010, Marques Johansson marq...@displague.com wrote: The company I work for, VOD.com (sfw) (aka Hotmovies .com and clips .com - nsfw (spaces added)), offer video on demand services to thousands of If I understand correctly, you are content distributors and video encoders. Yes. Customers can watch movies by purchasing packages of time or paying for DRM protected rentals or for some of our sites and videos they can pay for unprotected video. The protected content (rentals) comes in the form of WMV or DivX files using either DivX's service of Windows Media Server. So you sell copies for money and a promise to delete the copy after it's use. That's like selling a book, printing Burn after reading on it and calling yourself a library. Also the book shall not be used for unauthorized uses, e.g. put under a table foot, lent to a friend or read repeatedly. The latter two cases may be solved by going to the library and buying another copy, other can't. Many people see DRM as an hybrid between a lock and a automagical fire lighter. Yes, let's get Amazon MP3 and the Itunes store closed down immediately. I'm not lobbying for DRM inclusion into HTML5 - I'm looking for server side HTML or HTTP ways to limit transfer sizes. Once a user has bought a copy, the copy has been bought and how (often) he uses said copy isn't your probem. You've successfully distributed and charged for the content. Job's done. A technical user will probably be able to copy the video to permanent storage whatever you do. Multi-pricing can also be achieved by other means, such as by resolution crippling. Watermarking to aid with tracking down grand scale pirates seems to be an OK thing to do. I know that a technical user will have the ability to do this. They will have at least paid for one copy. Server load can also be reduced by e.g. P2P, though users may want the price to drop in proportion to their uploads. I am using a standard video format and standard HTTP/HTML to distribute video. You don't see many P2P HTTP solutions around these days. Bandwidth isn't the issue in my case, but I would rather have the user disconnect from the server and play the video they've got before requesting more. The less open / throttled connections the server has to deal with the better it performs.
Re: [whatwg] More YouTube response
On Tue, 06 Jul 2010 15:19:35 +0200, Marques Johansson marq...@displague.com wrote: On Mon, Jul 5, 2010 at 10:25 PM, Henri Sivonen hsivo...@iki.fi wrote: On Jul 5, 2010, at 13:10, Marques Johansson wrote: For the content that is not protected the download or stream is metered so the client can be charged only for the time they spent watching the content. We error on the customer's side for things like buffering and misreported play segments. There'd be no problem if you were selling content by title (plus free trailer for sampling) instead of selling it by minute. If a user is paying for bandwidth why should they need to pay for a download of the full movie when they are only interested in a few scenes or a few key seconds of the video. A friend of mine called this weekend to confirm that a scene in Back to the Future 3 that has been popping up online was actually in the movie and not just some Internet hoax. He called to have me watch a particular segment on the DVD. I watched all of 3 minutes of the movie to confirm the original scene contents. Doc Brown's young blond haired train companion (who only appears at the end of the movie) displays a very preverse set of gestures in his 10 seconds of screen time that should have been edited out (I dodged all spoilers). There is a market for this kind of viewing habit that does not insist on the consumer purchasing a full right/license to the entire video nor the bandwidth or storage to accommodate it. When you are selling adult content - many users are much happier to pay for a few minutes of content that they seek through rather than a full movie that they will have little interest in watching again. The difference can easily be $.16 versus $16. As for trailers, many of our plans include additional time and all users that have ever purchased get 3 free 30 second plays weekly. That being said, I don't think the business models of one of the largest online video markets should put be on trial through a by a standards list. I think the discussion that DRM is irrelevant has its merits, but the contracts and services at play have a real value regardless of how distribution is restricted. I think the technology providers shouldn't feel an obligation to cater to particular contract models--especially when it complicates the technology. It makes more sense to draft contracts that are reasonable given the technology. (An example of a contract that I think technology providers shouldn't attempt to cater for is a content licensing contract that tries to distinguish between desktops, mobile devices and TVs. Such a contract makes no sense when devices of any kind can support the same standards.) I think providers cater to the technology that's available. At the time these contracts were drawn up Windows Media player and Real were leading the streaming video market. The contracts and services in place now were created pre-Youtube, when most users accessed the site with a 56 modem or less. The service was geared toward online streaming and streaming rentals rather than downloads - which could take some users days to complete - or longer when coupled with bad re-try behaviors in browsers. Cell phones couldn't play let alone download a video over their 14kbps connection. For my purposes I am interested in application-controlled video delivery. I want to be able to deliver unprotected mp4, webm, or ogv content in a metered way. If the user has payed to watch the entire video once and has managed to work around HTTP no-cache and the other constraints that a normal browser viewed experience would have, then they will have succeeding in downloading a copy of the video - a task which they could have accomplished with a VM session or through other means regardless of DRM. If the customers pay for seeing an entire title, why is it a problem if a customer once in a while downloads the bytes twice? Surely it is simpler to bake the average bandwidth cost into the price and not complicate the way the delivery technology behaves. We have different plans available. Some allow a user to stream a chosen video as often as they want. There are plans that allow users to stream an entire studios selection of videos on demand. This likens the service to a monthly membership site and the company I work for has found that many users prefer to not have that sort of commitment - preferring instead to pay for what they watch when they watch it. The choice is determined by the content provider and the user - we accomodate both parties to the best of our ability. These requests can be seen as generally allowing servers to reduce load for video or large file downloads. Since a client may be able to download 5 minutes of video in under a minute I would like to see the client disconnect from the server and reconnect in 5 minutes to get the additional content. Wouldn't
Re: [whatwg] More YouTube response
On Mon, Jul 5, 2010 at 4:26 PM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: On Mon, Jul 5, 2010 at 4:10 PM, Marques Johansson marq...@displague.com wrote: For my purposes I am interested in application-controlled video delivery. I want to be able to deliver unprotected mp4, webm, or ogv content in a metered way. If the user has payed to watch the entire video once and has managed to work around HTTP no-cache and the other constraints that a normal browser viewed experience would have, then they will have succeeding in downloading a copy of the video - a task which they could have accomplished with a VM session or through other means regardless of DRM. There's no way to stop this at the markup level, since the user could just configure a user-agent to ignore the attributes, or manually remove them with a tool like Firebug. More to the point, since this feature doesn't provide significant benefit to many users or authors, no user agent would bother implementing it in the first place. You should instead look into to writing server-side scripts that meet your needs. When the user requests a video, have the script check how much video the user is authorized to view, and just truncate it after that point. Or have it insert an extra clip at the end of what they're allowed to view saying you have to pay more to keep viewing, then truncate it. Or whatever. This is pretty easy to do, and not possible for the user to circumvent. If the UA didn't follow the prescribed size constraints they would get a 403 response (or a better 4xx range too large if it existed). The benefit to the user is that they could have less open network connections while streaming video from server controlled sites and those sites will have the ability to meter their usage more accurately. Inserting an extra clip at the end is more of a playlist or scripting answer. Or perhaps a a live re-encoding answer. I'm looking for a way to give the user the raw video file in a metered way. A 200 response or partial 206 responses that returns less than the full requested range is not handled by browsers in a consistent or usable way (for this purpose). Only Chrome will continue to fetch where the previous short 206 response left off (request 1-10, server replies 1-5, request 6-10, server replies 6-10). The HTTP spec isn't clear about whether UAs should take this behavior - and so they don't. Some UAs request video without sending Range: bytes 0-. The server has no way to negotiate that the UA (a) must use ranges to complete the request or that (b) the range requested is too large, retry will a smaller range. These requests can be seen as generally allowing servers to reduce load for video or large file downloads. Since a client may be able to download 5 minutes of video in under a minute I would like to see the client disconnect from the server and reconnect in 5 minutes to get the additional content. I would like to see the server have the ability to enforce this (through HTTP errors) or at least suggest it (through HTML5 attributes or additional HTTP headers). Well-written clients should already buffer only as much as they need to ensure the video will play smoothly. The preload= attribute is already provided to allow authors to control this behavior. When the client has read enough for now, it will just stop reading new content from the server until it needs more. If the server thinks that the client is reading too fast, on the other hand, it can just send fewer packets. Again, I don't think anything needs to be changed in HTML here. All of the current video clients make requests like Range: 0- or (when you seek) Range: 0-end_of_file. I don't want to give them the whole 2gb file right now, they may seek to the end of the video at any moment while the server is paying to send that data and the transfer will have been wasted. I don't want to throttle the connection because that is also a waste of resources. I want the UA to request X many bytes (which equates to some fragment of time), disconnect if they will be busy beyond the keep-alive time, and come back when they need more video data. A 200 response and an unbounded 206 response do not permit this. If the video tag included a minbuffer and a maxbuffer (at least the latter) then the client would always have an upper bound on video ranges requested. If the UA failed to include this the server can give them a 403, 416, or some 4xx that does not yet exist.
Re: [whatwg] More YouTube response
On Tue, Jul 6, 2010 at 10:12 AM, Philip Jägenstedt phil...@opera.comwrote: On Tue, 06 Jul 2010 15:19:35 +0200, Marques Johansson marq...@displague.com wrote: Is preload=none not enough? I can't imagine the actual bandwidth savings of more fine-grained control to be significant, probably any attempt by the browser to stop buffering after some time is good enough. I have been using preload=metadata in my testing. If the browser fetches the metadata then they should be able to seek through the video more easily and should have all the information they need to make partial requests with upper bounds. Again - I have no HTML or HTTP way to suggest the UA only take X many bytes for now and come back later for more. Since I see you are with Opera - I noticed that Opera will play ogg files in a different way than webm files. The ogg handler will handle short 206 responses by making requests for the next range (client requests 0-10, server responds with a 206 status, bytes 0-5, client plays then fetches bytes 6-10). The webm handler will only play the range that was sent in the initial 206 (client requests 0-10, server responds with a 206 status, bytes 0-5, client stops playing). I also noticed that Opera will ignore no-cache headers on video content so a 206 fragment marked as no-cache can be rewinded and replayed without making additional requests. Chrome refetches the data. Looking at this as a pure HTTP matter I believe Chrome is taking the correct action.
Re: [whatwg] More YouTube response
On 6 Jul 2010, at 15:24, Marques Johansson wrote: A 200 response or partial 206 responses that returns less than the full requested range is not handled by browsers in a consistent or usable way (for this purpose). Only Chrome will continue to fetch where the previous short 206 response left off (request 1-10, server replies 1-5, request 6-10, server replies 6-10). The HTTP spec isn't clear about whether UAs should take this behavior - and so they don't. It might be easier to get that fixed in browsers, than to get spec+implementation of a completely new feature. Some UAs request video without sending Range: bytes 0-. The server has no way to negotiate that the UA (a) must use ranges to complete the request or that (b) the range requested is too large, retry will a smaller range. You could respond with HTTP/1.0 and close connection. You could split movie into separate video files and hide that fact in the player's UI (sort-of like Apple's HTTP live streaming). -- regards, Kornel
Re: [whatwg] More YouTube response
On Tue, 06 Jul 2010 16:33:47 +0200, Marques Johansson marq...@displague.com wrote: On Tue, Jul 6, 2010 at 10:12 AM, Philip Jägenstedt phil...@opera.comwrote: On Tue, 06 Jul 2010 15:19:35 +0200, Marques Johansson marq...@displague.com wrote: Is preload=none not enough? I can't imagine the actual bandwidth savings of more fine-grained control to be significant, probably any attempt by the browser to stop buffering after some time is good enough. I have been using preload=metadata in my testing. If the browser fetches the metadata then they should be able to seek through the video more easily and should have all the information they need to make partial requests with upper bounds. Again - I have no HTML or HTTP way to suggest the UA only take X many bytes for now and come back later for more. Opera hasn't implemented support for the preload attribute yet, I'm not sure what the status of other browsers are. I suspect that once all browsers have more conservative bandwidth management, the problem will be solved. Since I see you are with Opera - I noticed that Opera will play ogg files in a different way than webm files. The ogg handler will handle short 206 responses by making requests for the next range (client requests 0-10, server responds with a 206 status, bytes 0-5, client plays then fetches bytes 6-10). The webm handler will only play the range that was sent in the initial 206 (client requests 0-10, server responds with a 206 status, bytes 0-5, client stops playing). The demuxers and decoders are several layers away from the actual HTTP requests and responses, so I think the problem could be reproduced with either Ogg or WebM depending on chance. Opera doesn't handle the case where the server returns the wrong amount of data very well. Fortunately, I've seen no live servers doing this yet. I also noticed that Opera will ignore no-cache headers on video content so a 206 fragment marked as no-cache can be rewinded and replayed without making additional requests. Chrome refetches the data. Looking at this as a pure HTTP matter I believe Chrome is taking the correct action. Thanks, I've noted this in our bug tracking system. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] More YouTube response
On Tue, 06 Jul 2010 16:24:45 +0200, Marques Johansson marq...@displague.com wrote: On Mon, Jul 5, 2010 at 4:26 PM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: On Mon, Jul 5, 2010 at 4:10 PM, Marques Johansson marq...@displague.com wrote: For my purposes I am interested in application-controlled video delivery. I want to be able to deliver unprotected mp4, webm, or ogv content in a metered way. If the user has payed to watch the entire video once and has managed to work around HTTP no-cache and the other constraints that a normal browser viewed experience would have, then they will have succeeding in downloading a copy of the video - a task which they could have accomplished with a VM session or through other means regardless of DRM. There's no way to stop this at the markup level, since the user could just configure a user-agent to ignore the attributes, or manually remove them with a tool like Firebug. More to the point, since this feature doesn't provide significant benefit to many users or authors, no user agent would bother implementing it in the first place. You should instead look into to writing server-side scripts that meet your needs. When the user requests a video, have the script check how much video the user is authorized to view, and just truncate it after that point. Or have it insert an extra clip at the end of what they're allowed to view saying you have to pay more to keep viewing, then truncate it. Or whatever. This is pretty easy to do, and not possible for the user to circumvent. If the UA didn't follow the prescribed size constraints they would get a 403 response (or a better 4xx range too large if it existed). The benefit to the user is that they could have less open network connections while streaming video from server controlled sites and those sites will have the ability to meter their usage more accurately. Inserting an extra clip at the end is more of a playlist or scripting answer. Or perhaps a a live re-encoding answer. I'm looking for a way to give the user the raw video file in a metered way. A 200 response or partial 206 responses that returns less than the full requested range is not handled by browsers in a consistent or usable way (for this purpose). Only Chrome will continue to fetch where the previous short 206 response left off (request 1-10, server replies 1-5, request 6-10, server replies 6-10). The HTTP spec isn't clear about whether UAs should take this behavior - and so they don't. Some UAs request video without sending Range: bytes 0-. The server has no way to negotiate that the UA (a) must use ranges to complete the request or that (b) the range requested is too large, retry will a smaller range. The first request is tricky for the browser too. Having no idea of how big the resource is or what the bitrate is, there is no bounded request that makes sense, in my opinion. The downside is that for a conservative approach, the only solution is to abort the connection half way through, with the server having no idea when this will happen. I haven't seen any negative effects of this in practice yet, but this thread has me thinking that it could be better. Handling a short reply gracefully would be a good start. These requests can be seen as generally allowing servers to reduce load for video or large file downloads. Since a client may be able to download 5 minutes of video in under a minute I would like to see the client disconnect from the server and reconnect in 5 minutes to get the additional content. I would like to see the server have the ability to enforce this (through HTTP errors) or at least suggest it (through HTML5 attributes or additional HTTP headers). Well-written clients should already buffer only as much as they need to ensure the video will play smoothly. The preload= attribute is already provided to allow authors to control this behavior. When the client has read enough for now, it will just stop reading new content from the server until it needs more. If the server thinks that the client is reading too fast, on the other hand, it can just send fewer packets. Again, I don't think anything needs to be changed in HTML here. All of the current video clients make requests like Range: 0- or (when you seek) Range: 0-end_of_file. I don't want to give them the whole 2gb file right now, they may seek to the end of the video at any moment while the server is paying to send that data and the transfer will have been wasted. I don't want to throttle the connection because that is also a waste of resources. I want the UA to request X many bytes (which equates to some fragment of time), disconnect if they will be busy beyond the keep-alive time, and come back when they need more video data. A 200 response and an unbounded 206 response do not permit this. If the video tag included a minbuffer and a maxbuffer (at
Re: [whatwg] More YouTube response
On Tue, Jul 6, 2010 at 10:59 AM, Philip Jägenstedt phil...@opera.comwrote: On Tue, 06 Jul 2010 16:24:45 +0200, Marques Johansson marq...@displague.com wrote: Some UAs request video without sending Range: bytes 0-. The server has no way to negotiate that the UA (a) must use ranges to complete the request or that (b) the range requested is too large, retry will a smaller range. The first request is tricky for the browser too. Having no idea of how big the resource is or what the bitrate is, there is no bounded request that makes sense, in my opinion. The downside is that for a conservative approach, the only solution is to abort the connection half way through, with the server having no idea when this will happen. I haven't seen any negative effects of this in practice yet, but this thread has me thinking that it could be better. Handling a short reply gracefully would be a good start. For webm files, Chrome requests 0-1024 and then some block near the end of the file. I assume that the meta data / time ranges are stored at these locations. As for bounded requests that make sense - I'm sure the server hosting the content could suggest something ;-) I've tried having the server disconnect a HTTP/1.1 200 response by doing a php exit() before having sent the Content-Length specified number of bytes. Browsers did not attempt to pick up where the server left off. I think you are suggesting that the client disconnect but without scripting I don't really have control over that and if with scripting that doesn't seem doable unless the video element could be feed with an appendBytes() type of function.
Re: [whatwg] More YouTube response
On Tue, Jul 6, 2010 at 10:24 AM, Marques Johansson marq...@displague.com wrote: The benefit to the user is that they could have less open network connections while streaming video from server controlled sites and those sites will have the ability to meter their usage more accurately. Inserting an extra clip at the end is more of a playlist or scripting answer. Or perhaps a a live re-encoding answer. I'm looking for a way to give the user the raw video file in a metered way. It sounds like your use-case is very special, and best handled by script. I suggested server-side script -- you could do that today. Just cut off the HTTP connection when the user has used up their allotted time. Alternatively, it might be reasonable to have client-side scripting for video that's flexible enough to do what you want. But a dedicated declarative feature is just not reasonable for such a specific purpose. A 200 response or partial 206 responses that returns less than the full requested range is not handled by browsers in a consistent or usable way (for this purpose). Only Chrome will continue to fetch where the previous short 206 response left off (request 1-10, server replies 1-5, request 6-10, server replies 6-10). The HTTP spec isn't clear about whether UAs should take this behavior - and so they don't. Some UAs request video without sending Range: bytes 0-. The server has no way to negotiate that the UA (a) must use ranges to complete the request or that (b) the range requested is too large, retry will a smaller range. You don't need to return less than the browser requests, until it actually uses up the bandwidth the user has paid for. Let the browser fetch as much of the video as the user wants to view, using preload=metadata when that's supported by all browsers. Every time the server sends a new chunk of video to the user, it should deduct that much from the user's current balance. When the user has received as much video as he's paid for, just have the script exit without sending more output. You don't have to return a proper Range header and expect the browser to issue new requests. Just pretend you're serving the whole resource, then cut it off unexpectedly before you've actually returned all the content. The browser will handle this fine, it will just treat it as a network error. A client-side script can then detect the error and present nice UI. All of the current video clients make requests like Range: 0- or (when you seek) Range: 0-end_of_file. I don't want to give them the whole 2gb file right now, they may seek to the end of the video at any moment while the server is paying to send that data and the transfer will have been wasted. I don't want to throttle the connection because that is also a waste of resources. I want the UA to request X many bytes (which equates to some fragment of time), disconnect if they will be busy beyond the keep-alive time, and come back when they need more video data. A 200 response and an unbounded 206 response do not permit this. This part is handled by the preload attribute already. You just have to wait for browsers to actually support it.
Re: [whatwg] More YouTube response
On Jul 6, 2010, at 06:19, Marques Johansson wrote: That being said, I don't think the business models of one of the largest online video markets should put be on trial through a by a standards list. Well, if you are suggesting that your use case needs to be addressed by introducing browser-side features, putting the use case on trial is a routine part of how specs are developed at the WHATWG. In particular, it's worthwhile to examine if the use case or a close approximation thereof could be addressed without adding features to the browser side. One crude approximation would be breaking the video title into chunks similar to the chunks between commercials on TV such that each chunk would be a video file and a JS-based UI would continue from one chunk to the next. This way, billing could be per chunk. (But see below for an even better way.) Partial requests are native to HTTP and seeking is natural for a healthy streamed viewing habit - I'm look for a way to get the browser to take the servers recommendation that the content be fetched in a particular way - we have content negotiation of transfer encoding and image quality, why not allow the server to negotiate the transfer size for the benefit of the user and the server? I think it's not particularly natural to put bandwidth rate control on the browser side or on/above the HTTP layer. I think it's more natural to control bandwidth on the TCP level, and, of the two sides of TCP, the server is the one that you can trust to do it per your parameters. The server could write data into the TCP stream only a little ahead of the playback time. This way, you could assume that the video has been played to the precision of how much data you send ahead of the playback position. To know the playback position, you could have a JS-based video player send the current playback position to the server periodically using XHR or a Web Socket connection. Whenever you receive a playback position heartbeat, you'd flush a bit more data into the video file's TCP stream and account it as viewed. Downsides: Two TCP connections instead of one, but having two data channels isn't so different from RTSP/RTP. Upsides: No additional browser features required. No need to trust the browser to do bandwidth rate control according to your parameters, since you decide how often to send the heartbeat and how much data to send per heartbeat. Avoidance of the header overhead of multiple HTTP requests (in the Web Socket case--not in the XHR case). -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] More YouTube response
2010-07-05 01:56 EEST: David Gerard: On 4 July 2010 13:57, bjartursvartma...@gmail.com wrote: I fail to see how BBC would be harmed by the usage of alternative software. Its business model is about content, not software, right? See, you're using logic and sense ... about half the BBC want to just *make their stuff available*, the other half are worried about the thicket of laws and agreements that made sense in the days of analogue tape broadcast on analogue television that, despite not making sense on the Internet, still bind them legally. (Broadcast rights, residuals for actors and writers, etc.) These are serious and real concerns and they can't just ignore them. So, you're arguing that DRM is not required, right? Basically the whole problem is about how current content distributors (e.g. BBC) have made stupid contracts in the history and are trying to work around those stupid contracts with DRM instead of doing the right thing and do one of the following: (1) renegotiate the contracts to allow redistribution, or (2) stop trying to redistribute content you don't have proper rights to do. Especially, the content distributors should immediately stop pretending that DRM allows for any kind of protection. It's mathematically impossible. It's like trying to send an encrypted message to Bob with a requirement that Bob cannot have access to the message. That problem cannot be solved. For that problem, a decision needs to be made: (1) Bob is allowed to get access to the message, or (2) Bob is not allowed to get access to the message (never send it!) Notice how this is similar to the DRM case above? Introducing a DRM system is about *trying to not do the decision* if you really *want to distribute the content or not*. Such system should not ever be standardized because it really cannot ever work, by definition. -- Mikko
Re: [whatwg] More YouTube response
On 5 July 2010 07:51, Mikko Rantalainen mikko.rantalai...@peda.net wrote: So, you're arguing that DRM is not required, right? I'm arguing that it can't possibly make sense. And that standardising a DRM is not something anyone sensible should touch. Especially, the content distributors should immediately stop pretending that DRM allows for any kind of protection. It's mathematically impossible. It's like trying to send an encrypted message to Bob with a requirement that Bob cannot have access to the message. That problem cannot be solved. For that problem, a decision needs to be made: (1) Bob is allowed to get access to the message, or (2) Bob is not allowed to get access to the message (never send it!) Notice how this is similar to the DRM case above? Introducing a DRM system is about *trying to not do the decision* if you really *want to distribute the content or not*. Such system should not ever be standardized because it really cannot ever work, by definition. Yes, precisely. Law can contain absurdities - in the BBC case above, streaming and downloading are legally different things, even though technically they're identical - but putting such absurdities into a technical spec is nonsensical. - d.
Re: [whatwg] More YouTube response
Hi John, Many good responses and I agree with most but, what I think would work best is having a means for 3rd party DRM providers to supply browser plug-ins which implement the video tag for protected content, I am not so sure. Is one of the reasons for tags such as video not to move away from third party plugin's and have this baked into the UA instead? The general idea is good, I just believe implementing this via 3rd party plugin's is not the best way forward. Schalk Neethling From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of John Harding Sent: Friday, July 02, 2010 1:00 AM To: wha...@whatwg.org Cc: Andy Berkheimer Subject: [whatwg] More YouTube response Glad to see my post spurred some good discussion - I'll try to address topic by topic below, but one of the great points made is that some of the functionality YouTube needs from browsers probably doesn't belong in the HTML5 spec (e.g. streaming, content protection). I'm happy to take those discussions elsewhere if this forum is inappropriate, but it seems like it would likely be the same group of people, just on a different mailing list. 1. Standard Video Format Yes, this has been debated a lot, and I generally agree that leaving it out of the spec was the best way forward for the spec. Shane Fagan pointed out that Flash supports multiple different codecs, which is true, but every version since Flash 7 has supported Sorenson Spark video and MP3 audio. I don't think anyone is suggesting that browsers shouldn't support multiple codecs, but having a consistent baseline is important. On the current path, a content provider knows that by offering H.264 and WebM, they can reach all HTML5-capable browsers. This honestly is a reasonable state for YouTube right now - we use H.264 in cases outside the video tag as well, but it would be nice to converge on a single baseline format at some point in the future. 2. Robust Video Streaming Andy Berkheimer on our team has been putting some thought into this, so I'll defer to him for more specific proposals. For an app like YouTube, it is extremely useful to have fine-grained control over how the browser fetches media from the server. Whether the details belong in the HTML5 spec or not depends on the preferred design - something similar to Flash 10.1's appendBytes() mechanism would affect the video tag interface, for example, while a transport protocol could be completely separate. 3. Content Protection Some of the discussion here seems to have conflated application-controlled video delivery with content protection, but in an ideal world, the two are independent. The basic requirements around content protection that we get from content owners basically consist of encrypting the content and limiting the decryption to a verified and authorized client - the realm of traditional DRM. Rather than ask browsers to get into the DRM business, what I think would work best is having a means for 3rd party DRM providers to supply browser plug-ins which implement the video tag for protected content - not all that different than selecting a pluggable codec. 4. Encapsulation and Embedding As several people pointed out (and which I tried to get at in my post), this is really an ecosystem issue rather than a change needed in the spec or in browsers. I suspect it's going to take some time, but the flexibility of embedding content via iframe will be a big step forward. 5. Fullscreen Maciej actually covered YouTube's requirements pretty well. I'd add that it's not just controls that are important for us to maintain: we have a lot of additional content that needs to display with and sometimes on top of the video - our interactive annotations, captions, and ads most notably. Maciej's proposal also looks fairly reasonable, though some thoughts on it: When limiting keyboard input, I'd suggest devices w/ onscreen keyboards simply disable the keyboard. Applications that work well with touch interfaces generally provide gesture alternatives for the limited set of keys that would be available. Alternately, devices could limit the keyboard to the set of allowed keys. Keyboard restrictions are better than not having fullscreen support, though they do limit functionality - it would prevent us from supporting search in fullscreen mode, for example. 6. Camera and Micrphone access As pointed out, this is not strictly an issue for video tag, though certainly related especially for local preview. I have not been closely following the work on the device element, though that seems to be where this is headed. -John
Re: [whatwg] More YouTube response
John Harding jhard...@google.com schrieb am Thu, 1 Jul 2010 15:59:37 -0700: 1. Standard Video Format […] On the current path, a content provider knows that by offering H.264 and WebM, they can reach all HTML5-capable browsers. This honestly is a reasonable state for YouTube right now - we use H.264 in cases outside the video tag as well, but it would be nice to converge on a single baseline format at some point in the future. Practically, I think the ball is / was in Apple's court to decide this. While to this day other browser makers have decided to ship two (!) royalty-free video formats (Theora and VP8), Apple is the single H.264 holdout, and they have a tight itegration to their hardware as well. Sadly, I do not have hope for any consolidation regarding video formats. And while Youtube may be fine with having to provide only two formats instead of a dozen, for the common smaller webmaster this is a significant task, as transcoding resources are limited. Recently, I have been discussing video implementation with the administrator of an imageboard. It was ultimately decided to not add this feature, precisely because of the multitude of video formats of which none can be played in every modern browser. It's a shame. […] 3. Content Protection […] The basic requirements around content protection that we get from content owners basically consist of encrypting the content and limiting the decryption to a verified and authorized client - the realm of traditional DRM. This can not possibly work if you have an open standard, which by design has to be implementable by everyone who cares, which includes a wide range of free and proprietary software vendors. Rather than ask browsers to get into the DRM business, what I think would work best is having a means for 3rd party DRM providers to supply browser plug-ins which implement the video tag for protected content - not all that different than selecting a pluggable codec. To define a feature like that would hurt an otherwise open standard and help to balkanize the browser market even more. If you really want to do this, why not just use flash / java / whatever can deliver using already available proprietary means ? […] Greetings, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net signature.asc Description: PGP signature
Re: [whatwg] More YouTube response
On Mon, 2010-07-05 at 17:45 +0200, Nils Dagsson Moskopp wrote: John Harding jhard...@google.com schrieb am Thu, 1 Jul 2010 15:59:37 -0700: 1. Standard Video Format […] On the current path, a content provider knows that by offering H.264 and WebM, they can reach all HTML5-capable browsers. This honestly is a reasonable state for YouTube right now - we use H.264 in cases outside the video tag as well, but it would be nice to converge on a single baseline format at some point in the future. Practically, I think the ball is / was in Apple's court to decide this. While to this day other browser makers have decided to ship two (!) royalty-free video formats (Theora and VP8), Apple is the single H.264 holdout, and they have a tight itegration to their hardware as well. Sadly, I do not have hope for any consolidation regarding video formats. And while Youtube may be fine with having to provide only two formats instead of a dozen, for the common smaller webmaster this is a significant task, as transcoding resources are limited. Recently, I have been discussing video implementation with the administrator of an imageboard. It was ultimately decided to not add this feature, precisely because of the multitude of video formats of which none can be played in every modern browser. It's a shame. If I remember correctly and dont ask me for a link to where I read it but the problem is still patent suits I believe. MPEG-LA as soon as they heard about the VP8 codec open sourcing they said they were getting a patent pool together to challenge its adoption anywhere. Although I believe that there is nothing to worry about because Google has a huge patent pool to fight back with. I think this issue is still a huge sticking point for everyone and I dont see a resolution other than to let everyone use whats comfortable and see what sticks. Its a waiting game im afraid but as for adding webm to the HTML5 spec I still dont think we can add it at this stage IMHO. As for Apple not picking it up you would have to ask someone at Apple. Id say its still the threat from MPEG-LA's patent pool that still hasnt attacked Theora like it said it would a few years back so it seems like an empty threat to me. --fagan
Re: [whatwg] More YouTube response
The company I work for, VOD.com (sfw) (aka Hotmovies .com and clips .com - nsfw (spaces added)), offer video on demand services to thousands of studios. Our sites are central locations for customers who want to watch something - this is a service in itself. We handle encoding and content distribution and streaming sales for these studios without any cost to them. They send us video content and we send them a monthly check. Without services like the ones we provide many of these studios (some are mom and pop shops) wouldn't otherwise have the ability to sell their content online in this fashion. Customers can watch movies by purchasing packages of time or paying for DRM protected rentals or for some of our sites and videos they can pay for unprotected video. The protected content (rentals) comes in the form of WMV or DivX files using either DivX's service of Windows Media Server. For the content that is not protected the download or stream is metered so the client can be charged only for the time they spent watching the content. We error on the customer's side for things like buffering and misreported play segments. I think the discussion that DRM is irrelevant has its merits, but the contracts and services at play have a real value regardless of how distribution is restricted. For my purposes I am interested in application-controlled video delivery. I want to be able to deliver unprotected mp4, webm, or ogv content in a metered way. If the user has payed to watch the entire video once and has managed to work around HTTP no-cache and the other constraints that a normal browser viewed experience would have, then they will have succeeding in downloading a copy of the video - a task which they could have accomplished with a VM session or through other means regardless of DRM. If we need additionally protection we can add watermarking to legally go after content thieves since we know the IP and username of the viewer in most cases. My requests have focused on things like video minbuffer=100k maxbuffer=200k which could also apply to a source element. I want to make sure that the browser always uses Range: bytes x-y in requests (since I have no other way to require that a browser use ranges or use ranges with an upper bound). I can use this tool to make sure UAs do not download more content than the user has watched (which costs them money in some way). I've also been suggesting HTTP changes that would permit this UA behavior (a 4xx for Ranges Required, a 4xx for Range too large, or explicitly defining that a 206 response can include less bytes than requested and the UA should follow-up with additional ranged requests). While an HTML5 solution is easy to make possible as their is no legacy to worry about and the spec is still floating about, an HTTP solution would allow me to provide metered content flow without leaving HTTP sessions open (throttling) and without the need for a video element - permitting users to use their native http streaming players. These requests can be seen as generally allowing servers to reduce load for video or large file downloads. Since a client may be able to download 5 minutes of video in under a minute I would like to see the client disconnect from the server and reconnect in 5 minutes to get the additional content. I would like to see the server have the ability to enforce this (through HTTP errors) or at least suggest it (through HTML5 attributes or additional HTTP headers). On Mon, Jul 5, 2010 at 2:51 AM, Mikko Rantalainen mikko.rantalai...@peda.net wrote: 2010-07-05 01:56 EEST: David Gerard: On 4 July 2010 13:57, bjartursvartma...@gmail.com wrote: I fail to see how BBC would be harmed by the usage of alternative software. Its business model is about content, not software, right? See, you're using logic and sense ... about half the BBC want to just *make their stuff available*, the other half are worried about the thicket of laws and agreements that made sense in the days of analogue tape broadcast on analogue television that, despite not making sense on the Internet, still bind them legally. (Broadcast rights, residuals for actors and writers, etc.) These are serious and real concerns and they can't just ignore them. So, you're arguing that DRM is not required, right? Basically the whole problem is about how current content distributors (e.g. BBC) have made stupid contracts in the history and are trying to work around those stupid contracts with DRM instead of doing the right thing and do one of the following: (1) renegotiate the contracts to allow redistribution, or (2) stop trying to redistribute content you don't have proper rights to do. Especially, the content distributors should immediately stop pretending that DRM allows for any kind of protection. It's mathematically impossible. It's like trying to send an encrypted message to Bob with a requirement that Bob cannot have access to the message. That problem cannot be
Re: [whatwg] More YouTube response
On Mon, Jul 5, 2010 at 11:45 AM, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: Practically, I think the ball is / was in Apple's court to decide this. While to this day other browser makers have decided to ship two (!) royalty-free video formats (Theora and VP8), Apple is the single H.264 holdout, and they have a tight itegration to their hardware as well. Internet Explorer 9 will not support VP8 unless the user manually installs the codec. This puts it at the same level of support as Safari has for Theora, as far as I know. So even if we assume every user upgraded to the latest alphas of the browser they used, H.264 is supported by about 65% of users' browsers, and VP8 by about 40%. Of course, in reality, less than half of users' browsers support video at all right now, and given IE uptake rates, that's only going to change slowly. On Mon, Jul 5, 2010 at 4:10 PM, Marques Johansson marq...@displague.com wrote: For my purposes I am interested in application-controlled video delivery. I want to be able to deliver unprotected mp4, webm, or ogv content in a metered way. If the user has payed to watch the entire video once and has managed to work around HTTP no-cache and the other constraints that a normal browser viewed experience would have, then they will have succeeding in downloading a copy of the video - a task which they could have accomplished with a VM session or through other means regardless of DRM. There's no way to stop this at the markup level, since the user could just configure a user-agent to ignore the attributes, or manually remove them with a tool like Firebug. More to the point, since this feature doesn't provide significant benefit to many users or authors, no user agent would bother implementing it in the first place. You should instead look into to writing server-side scripts that meet your needs. When the user requests a video, have the script check how much video the user is authorized to view, and just truncate it after that point. Or have it insert an extra clip at the end of what they're allowed to view saying you have to pay more to keep viewing, then truncate it. Or whatever. This is pretty easy to do, and not possible for the user to circumvent. These requests can be seen as generally allowing servers to reduce load for video or large file downloads. Since a client may be able to download 5 minutes of video in under a minute I would like to see the client disconnect from the server and reconnect in 5 minutes to get the additional content. I would like to see the server have the ability to enforce this (through HTTP errors) or at least suggest it (through HTML5 attributes or additional HTTP headers). Well-written clients should already buffer only as much as they need to ensure the video will play smoothly. The preload= attribute is already provided to allow authors to control this behavior. When the client has read enough for now, it will just stop reading new content from the server until it needs more. If the server thinks that the client is reading too fast, on the other hand, it can just send fewer packets. Again, I don't think anything needs to be changed in HTML here.
Re: [whatwg] More YouTube response
Internet Explorer 9 will not support VP8 unless the user manually installs the codec. This puts it at the same level of support as Safari has for Theora, as far as I know. So even if we assume every user upgraded to the latest alphas of the browser they used, H.264 is supported by about 65% of users' browsers, and VP8 by about 40%. Of course, in reality, less than half of users' browsers support video at all right now, and given IE uptake rates, that's only going to change slowly. For windows maybe there should be a .exe/.msi with the entire package of VP8+Theora+Vorbis or just VP8+Vorbis to make it easier to install but adoption isnt really our issue thats Microsoft's issue if WebM takes off. I dont foresee it being any harder than Adobe Flash to install for the regular user so websites could just direct users to the download if they dont have it already. Oh and IE is dropping in use according to the media over the past 3 months ever since the browser selection screen came so its becoming less of an issue in time. --fagan
Re: [whatwg] More YouTube response
On Mon, Jul 5, 2010 at 3:46 PM, Shane Fagan shanepatrickfa...@ubuntu.comwrote: Internet Explorer 9 will not support VP8 unless the user manually installs the codec. This puts it at the same level of support as Safari has for Theora, as far as I know. So even if we assume every user upgraded to the latest alphas of the browser they used, H.264 is supported by about 65% of users' browsers, and VP8 by about 40%. Of course, in reality, less than half of users' browsers support video at all right now, and given IE uptake rates, that's only going to change slowly. For windows maybe there should be a .exe/.msi with the entire package of VP8+Theora+Vorbis or just VP8+Vorbis to make it easier to install but adoption isnt really our issue thats Microsoft's issue if WebM takes off. I dont foresee it being any harder than Adobe Flash to install for the regular user so websites could just direct users to the download if they dont have it already. Oh and IE is dropping in use according to the media over the past 3 months ever since the browser selection screen came so its becoming less of an issue in time. --fagan The marketshare drop has been very small, about a percentage point a month. And Ian and other people in WHATWG made it our issue if Microsoft or Apple doesn't fully adopt WebM. He made it clear that unless all the browser vendors adopted a video format, it would never be specified in the spec as the baseline format to support. We do need a baseline format in the spec. Supporting video will be difficult unless content providers can be certain that a single format will be supported across the board
Re: [whatwg] More YouTube response
It's the iPhone and especially the iPad which has really pushed the adoption of HTML5 video. And afaik, you can't install WebM on them. To me (and my company) that's where the issue lies. Mike Wilcox http://clubajax.org m...@mikewilcox.net On Jul 5, 2010, at 3:46 PM, Shane Fagan wrote: Internet Explorer 9 will not support VP8 unless the user manually installs the codec. This puts it at the same level of support as Safari has for Theora, as far as I know. So even if we assume every user upgraded to the latest alphas of the browser they used, H.264 is supported by about 65% of users' browsers, and VP8 by about 40%. Of course, in reality, less than half of users' browsers support video at all right now, and given IE uptake rates, that's only going to change slowly. For windows maybe there should be a .exe/.msi with the entire package of VP8+Theora+Vorbis or just VP8+Vorbis to make it easier to install but adoption isnt really our issue thats Microsoft's issue if WebM takes off. I dont foresee it being any harder than Adobe Flash to install for the regular user so websites could just direct users to the download if they dont have it already. Oh and IE is dropping in use according to the media over the past 3 months ever since the browser selection screen came so its becoming less of an issue in time. --fagan
Re: [whatwg] More YouTube response
On 07/05/2010 04:46 PM, Shane Fagan wrote: For windows maybe there should be a .exe/.msi with the entire package of VP8+Theora+Vorbis or just VP8+Vorbis to make it easier to install There is: http://downloads.xiph.org/releases/oggdsf/opencodecs_0.84.17315.exe http://lists.xiph.org/pipermail/theora/2010-June/004065.html In addition to system codecs, the package also includes an ActiveX plugin that implements a limited form of video in IE 8. --Ben signature.asc Description: OpenPGP digital signature
Re: [whatwg] More YouTube response
Shane Fagan shanepatrickfa...@ubuntu.com schrieb am Mon, 05 Jul 2010 17:20:12 +0100: If I remember correctly and dont ask me for a link to where I read it but the problem is still patent suits I believe. MPEG-LA as soon as they heard about the VP8 codec open sourcing they said they were getting a patent pool together to challenge its adoption anywhere. MPEG LA cannot allow other video formats to succeed; that would hurt the fundamental purpose of the organisation. Considering this, it was entirely expected. Although I believe that there is nothing to worry about because Google has a huge patent pool to fight back with. First, Google fighting back is pure speculation. Second, VP8 getting attacked by MPEG LA (which would be a prerequisite for that scenario) is pure speculation as well. As far as I am aware of the issue, nothing has happened yet. I think this issue is still a huge sticking point for everyone and I dont see a resolution other than to let everyone use whats comfortable and see what sticks. That is, if anything sticks at all. Its a waiting game im afraid but as for adding webm to the HTML5 spec I still dont think we can add it at this stage IMHO. As Hixie has stated, HTML5 is primarlily a descriptive specification, not a prescriptive one. If vendors cannot agree for one reason or another, then something will not be specced. The only reasonable behaviour for web masters who wish to excert their influence would be to not support specific clients, same as many pages prompt you to upgrade Flash. Speaking for myself, the 3% or whatever Safari users coming to my blog are advised to install Xiph codecs to be able to check out my Podcast (please, no etymological arguments about the perceived iPod heritage of that word). But then I do not run a commercial operation — porn site operators will probably use every fallback they can and quickly adapt to new and relevant clients like the iPad. As for Apple not picking it up you would have to ask someone at Apple. Id say its still the threat from MPEG-LA's patent pool that still hasnt attacked Theora like it said it would a few years back so it seems like an empty threat to me. May Apple engineers on this list chime in and tell us if patent uncertainity is still an issue ? AFAIK neither Google, nor Mozilla, nor Apple have had difficulties. Or should I write to Apple legal regarding this query ? Greetings, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net signature.asc Description: PGP signature
Re: [whatwg] More YouTube response
Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net schrieb am Tue, 6 Jul 2010 00:42:13 +0200: May Apple engineers on this list chime in and tell us if patent uncertainity is still an issue ? AFAIK neither Google, nor Mozilla, nor Apple have had difficulties. s/nor Apple/nor Opera/ Apparently I am of duck today. Quack. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net signature.asc Description: PGP signature
Re: [whatwg] More YouTube response
On Mon, 5 Jul 2010, Marques Johansson marq...@displague.com wrote: The company I work for, VOD.com (sfw) (aka Hotmovies .com and clips .com - nsfw (spaces added)), offer video on demand services to thousands of studios. Our sites are central locations for customers who want to watch something - this is a service in itself. We handle encoding and content distribution and streaming sales for these studios without any cost to them. They send us video content and we send them a monthly check. Without services like the ones we provide many of these studios (some are mom and pop shops) wouldn't otherwise have the ability to sell their content online in this fashion. If I understand correctly, you are content distributors and video encoders. Customers can watch movies by purchasing packages of time or paying for DRM protected rentals or for some of our sites and videos they can pay for unprotected video. The protected content (rentals) comes in the form of WMV or DivX files using either DivX's service of Windows Media Server. So you sell copies for money and a promise to delete the copy after it's use. That's like selling a book, printing Burn after reading on it and calling yourself a library. Also the book shall not be used for unauthorized uses, e.g. put under a table foot, lent to a friend or read repeatedly. The latter two cases may be solved by going to the library and buying another copy, other can't. Many people see DRM as an hybrid between a lock and a automagical fire lighter. For the content that is not protected the download or stream is metered so the client can be charged only for the time they spent watching the content. We error on the customer's side for things like buffering and misreported play segments. This seems like a saner alternative. I think the discussion that DRM is irrelevant has its merits, but the contracts and services at play have a real value regardless of how distribution is restricted. For my purposes I am interested in application-controlled video delivery. I want to be able to deliver unprotected mp4, webm, or ogv content in a metered way. If the user has payed to watch the entire video once and has managed to work around HTTP no-cache and the other constraints that a normal browser viewed experience would have, then they will have succeeding in downloading a copy of the video - a task which they could have accomplished with a VM session or through other means regardless of DRM. If we need additionally protection we can add watermarking to legally go after content thieves since we know the IP and username of the viewer in most cases. Once a user has bought a copy, the copy has been bought and how (often) he uses said copy isn't your probem. You've successfully distributed and charged for the content. Job's done. A technical user will probably be able to copy the video to permanent storage whatever you do. Multi-pricing can also be achieved by other means, such as by resolution crippling. Watermarking to aid with tracking down grand scale pirates seems to be an OK thing to do. My requests have focused on things like video minbuffer=100k maxbuffer=200k which could also apply to a source element. I want to make sure that the browser always uses Range: bytes x-y in requests (since I have no other way to require that a browser use ranges or use ranges with an upper bound). I can use this tool to make sure UAs do not download more content than the user has watched (which costs them money in some way). I've also been suggesting HTTP changes that would permit this UA behavior (a 4xx for Ranges Required, a 4xx for Range too large, or explicitly defining that a 206 response can include less bytes than requested and the UA should follow-up with additional ranged requests). While an HTML5 solution is easy to make possible as their is no legacy to worry about and the spec is still floating about, an HTTP solution would allow me to provide metered content flow without leaving HTTP sessions open (throttling) and without the need for a video element - permitting users to use their native http streaming players. These requests can be seen as generally allowing servers to reduce load for video or large file downloads. Since a client may be able to download 5 minutes of video in under a minute I would like to see the client disconnect from the server and reconnect in 5 minutes to get the additional content. I would like to see the server have the ability to enforce this (through HTTP errors) or at least suggest it (through HTML5 attributes or additional HTTP headers). Server load can also be reduced by e.g. P2P, though users may want the price to drop in proportion to their uploads.
Re: [whatwg] More YouTube response
On Jul 5, 2010, at 13:10, Marques Johansson wrote: For the content that is not protected the download or stream is metered so the client can be charged only for the time they spent watching the content. We error on the customer's side for things like buffering and misreported play segments. There'd be no problem if you were selling content by title (plus free trailer for sampling) instead of selling it by minute. I think the discussion that DRM is irrelevant has its merits, but the contracts and services at play have a real value regardless of how distribution is restricted. I think the technology providers shouldn't feel an obligation to cater to particular contract models--especially when it complicates the technology. It makes more sense to draft contracts that are reasonable given the technology. (An example of a contract that I think technology providers shouldn't attempt to cater for is a content licensing contract that tries to distinguish between desktops, mobile devices and TVs. Such a contract makes no sense when devices of any kind can support the same standards.) For my purposes I am interested in application-controlled video delivery. I want to be able to deliver unprotected mp4, webm, or ogv content in a metered way. If the user has payed to watch the entire video once and has managed to work around HTTP no-cache and the other constraints that a normal browser viewed experience would have, then they will have succeeding in downloading a copy of the video - a task which they could have accomplished with a VM session or through other means regardless of DRM. If the customers pay for seeing an entire title, why is it a problem if a customer once in a while downloads the bytes twice? Surely it is simpler to bake the average bandwidth cost into the price and not complicate the way the delivery technology behaves. These requests can be seen as generally allowing servers to reduce load for video or large file downloads. Since a client may be able to download 5 minutes of video in under a minute I would like to see the client disconnect from the server and reconnect in 5 minutes to get the additional content. Wouldn't this be a non-problem if the customers paid by title? In that case, it would seem pointless to worry about the content getting downloaded faster than it is played. It seems to me that your problem is picking a pricing model that's unnatural for the technology. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] More YouTube response
Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2010-07-02 21:01, John Harding wrote: On Fri, Jul 2, 2010 at 5:50 AM, Lachlan Huntlachlan.h...@lachy.id.auwrote: As Henri pointed out, major content producers already broadcast their TV shows and movies over the air without DRM. Although the BBC iPlayer uses DRM for the desktop version, they broadcast the show DRM free over the air and they make DRM free content available to the iPhone. People have even found ways to access that from other devices too. So the DRM really isn't there to protect the content. It's just to force users to use the BBC's own iPlayer software, rather than letting users use their own choice of software. I fail to see how BBC would be harmed by the usage of alternative software. Its business model is about content, not software, right? The industry even releases content on DVD knowing that the DRM is completely ineffective, because they only use it so they can control the DVD player market, rather than actually doing anything practical about illegal copying. How can the industry have control over the DVD player market and not their own government-designated markets?
Re: [whatwg] More YouTube response
On Fri, Jul 2, 2010 at 3:09 PM, John Harding jhard...@google.com wrote: Yes, it's pretty straightforward to offer iframe-based embed code, but it needs to be coupled with getting sites to accept them, or we end up with a lot of confused, unhappy users. This will only happen if the iframe support is widely advertised, though. I assume that practically everyone who embeds YouTube videos just copies the code given under the video. If iframe support were only mentioned in out-of-the-way places (like only if you've opted into the HTML5 beta) and labeled with only use this if you're sure you don't want the normal embed code, it would allow people who cared to use it, and they could push sites to whitelist it if any don't. This is probably low-priority from your perspective, I can see that. But it's pretty sad when the IE blog is now consistently using video instead of Flash, while the Chrome blog only uses Flash embeds (because of the YouTube dependency). Note that sites don't generally whitelist specific SWFs - they generally allow all Flash embeds. I'd be very surprised if major sites allowed arbitrary Flash but not arbitrary iframe. The former is extremely dangerous, the latter is not (although it could still create annoying popups, etc.). Do you have an example of such a site? On Fri, Jul 2, 2010 at 4:56 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: YouTube would do better to address this issue by bringing the major players in the content industry to the table to discuss methods of publishing their content in interoperable ways without DRM. Given how many lawsuits those major players have filed against Google *despite* concessions on DRM, I don't think it's practical to suggest that Google should provoke them even *more*. However, this isn't something standards groups have to deal with, since standardized DRM is more or less a contradiction in terms (in the absence of hardware support). Flash can continue to be used for video indefinitely where DRM is desired, just as Flash is occasionally used for still image galleries to prevent easy copying.
Re: [whatwg] More YouTube response
On 4 July 2010 13:57, bjartur svartma...@gmail.com wrote: I fail to see how BBC would be harmed by the usage of alternative software. Its business model is about content, not software, right? See, you're using logic and sense ... about half the BBC want to just *make their stuff available*, the other half are worried about the thicket of laws and agreements that made sense in the days of analogue tape broadcast on analogue television that, despite not making sense on the Internet, still bind them legally. (Broadcast rights, residuals for actors and writers, etc.) These are serious and real concerns and they can't just ignore them. It's all very complicated when real money is at stake. (c.f. The Innovator's Dilemma.) That said: DRM is a provably broken concept. Anyone who demands it be incorporated into a standard is fundamentally, deeply wrong and can work around it with some sort of proprietary plugin, because that way they won't be requiring anyone else to pretend mathematics doesn't work. - d.
Re: [whatwg] More YouTube response
On Sun, 2010-07-04 at 23:56 +0100, David Gerard wrote: On 4 July 2010 13:57, bjartur svartma...@gmail.com wrote: I fail to see how BBC would be harmed by the usage of alternative software. Its business model is about content, not software, right? See, you're using logic and sense ... about half the BBC want to just *make their stuff available*, the other half are worried about the thicket of laws and agreements that made sense in the days of analogue tape broadcast on analogue television that, despite not making sense on the Internet, still bind them legally. (Broadcast rights, residuals for actors and writers, etc.) These are serious and real concerns and they can't just ignore them. It's all very complicated when real money is at stake. (c.f. The Innovator's Dilemma.) That said: DRM is a provably broken concept. Anyone who demands it be incorporated into a standard is fundamentally, deeply wrong and can work around it with some sort of proprietary plugin, because that way they won't be requiring anyone else to pretend mathematics doesn't work. - d. I agree. I don't condone illegally distributing digital content, but DRM doesn't have a good track record. At best, it disrupts illegal copyright infringement, at its worst, it harms the honest consumer. The game Spore was arguably one of the most copyrighted games ever, despite (or maybe because of) its almost draconian DRM. DVD's suffered for a long time with being locked into regions by DRM, making it difficult for people who travelled a lot but wanted to watch films, and made little or no impact on those that obtained an illegal DRM-free copy. There are countless more tales all like this, but until a fiscally viable alternative is offered to the media companies (as let's face it, it's not the artists pushing for DRM!) then we will continue to see more measures brought into place and broken. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] More YouTube response
David Gerard dger...@gmail.com wrote: On 4 July 2010 13:57, bjartur svartma...@gmail.com wrote: I fail to see how BBC would be harmed by the usage of alternative software. Its business model is about content, not software, right? See, you're using logic and sense ... about half the BBC want to just *make their stuff available*, the other half are worried about the thicket of laws and agreements that made sense in the days of analogue tape broadcast on analogue television that, despite not making sense on the Internet, still bind them legally. (Broadcast rights, residuals for actors and writers, etc.) These are serious and real concerns and they can't just ignore them. AFAIK BBC hasn't been harmed by the usage of VHS players made and distributed by 3rd partys nor do I know about any laws that require them to technically and legally restrict consumer ability to play their media with their ware of choice. Limiting who and how their media can be consumed should harm BBC rather than the other way around.
Re: [whatwg] More YouTube response
John Harding jhard...@google.com wrote: Rather than ask browsers to get into the DRM business, what I think would work best is having a means for 3rd party DRM providers to supply browser plug-ins which implement the video tag for protected content - not all that different than selecting a pluggable codec. I think this would defeat a huge chunk of the value of video. A big part of the value of video is that competition and innovation on the computing platform space will be fostered when the vendor of a computing platform can port (or have ported) one of the Open Source browsers to the platform, pay Opera to port Presto or write their own (like Microsoft) without having to persuade a plug-in proprietor that it's worth the plug-in proprietor's effort to port a certain plug-in to the platform. Pluggable DRM or codec modules would regress back to the situation where the proprietors of those plug-ins act as gatekeepers for the success of computing platforms. I observe that Hollywood movies (the most premium of content, supposedly) are routinely licensed for DVB broadcast without DRM, and on the Internet every other form of content is distributed without DRM. It may well be that when the potential audience grows enough, at some point the ability to reach that audience weighs more than protection and the problem gets solved without DRM (and without the ill effects of DRM to computing platform freedom, competition and innovation). -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] More YouTube response
On Thu, Jul 1, 2010 at 6:59 PM, John Harding jhard...@google.com wrote: 2. Robust Video Streaming Andy Berkheimer on our team has been putting some thought into this, so I'll defer to him for more specific proposals. For an app like YouTube, it is extremely useful to have fine-grained control over how the browser fetches media from the server. Whether the details belong in the HTML5 spec or not depends on the preferred design - something similar to Flash 10.1's appendBytes() mechanism would affect the video tag interface, for example, while a transport protocol could be completely separate. 3. Content Protection Some of the discussion here seems to have conflated application-controlled video delivery with content protection, but in an ideal world, the two are independent. The basic requirements around content protection that we get I was muddling my recent requests related to browser fetch behavior and application-controlled video delivery: with the despised topic of DRM and content protection. Thanks for clearing that up, John. If a seek on a HTMLMediaElement's exposed and passed along the XHR Request to a fetcher method then I could set my constraints for the impending request. I would add HTTP Range headers if they are not present and set a Range upper bound (since the server will return 402,403, or 416 on any Range: bytes x- request to retrieve the full remaining content). The initiating caller would need to understand that the length of data requested may have shrunk (which would require the browser to seek again when the content was all played up or when the buffer was running low - things that should already be in place). This, to me, seems like an alternative to an addBytes method (if that does what I think it does). This would provide me with a strictly Javascript solution. Other methods I have been asking for would give me a purely HTTP solution (with new range related 4xxs and, spec endorsed, shorter than requested 206 responses) to achieve this or an HTML solution (using new video+source element attributes for buffer (min request size) and max request size).
Re: [whatwg] More YouTube response
On Fri, 2010-07-02 at 02:37 -0700, Henri Sivonen wrote: John Harding jhard...@google.com wrote: Rather than ask browsers to get into the DRM business, what I think would work best is having a means for 3rd party DRM providers to supply browser plug-ins which implement the video tag for protected content - not all that different than selecting a pluggable codec. I think this would defeat a huge chunk of the value of video. A big part of the value of video is that competition and innovation on the computing platform space will be fostered when the vendor of a computing platform can port (or have ported) one of the Open Source browsers to the platform, pay Opera to port Presto or write their own (like Microsoft) without having to persuade a plug-in proprietor that it's worth the plug-in proprietor's effort to port a certain plug-in to the platform. Pluggable DRM or codec modules would regress back to the situation where the proprietors of those plug-ins act as gatekeepers for the success of computing platforms. I observe that Hollywood movies (the most premium of content, supposedly) are routinely licensed for DVB broadcast without DRM, and on the Internet every other form of content is distributed without DRM. It may well be that when the potential audience grows enough, at some point the ability to reach that audience weighs more than protection and the problem gets solved without DRM (and without the ill effects of DRM to computing platform freedom, competition and innovation). Hey Henri, Well this isnt really a list where we should talk about the dos and donts of web content distribution. DRM content can be embedded in the video tag and decoded using installable plugins so its not really an issue for this list I dont think. We cant dictate how the specs are used so try to keep the conversation technology neutral. --fagan
Re: [whatwg] More YouTube response
If the seek method was further hookable it should be possible to add decrypt or transcode methods to interpret the fetched content, possibly requesting more data to the filter stream bucket, before apending the bytes of media. On Jul 2, 2010 6:10 AM, Marques Johansson marq...@displague.com wrote: On Thu, Jul 1, 2010 at 6:59 PM, John Harding jhard...@google.com wrote: 2. Robust Video Streamin... I was muddling my recent requests related to browser fetch behavior and application-controlled video delivery: with the despised topic of DRM and content protection. Thanks for clearing that up, John. If a seek on a HTMLMediaElement's exposed and passed along the XHR Request to a fetcher method then I could set my constraints for the impending request. I would add HTTP Range headers if they are not present and set a Range upper bound (since the server will return 402,403, or 416 on any Range: bytes x- request to retrieve the full remaining content). The initiating caller would need to understand that the length of data requested may have shrunk (which would require the browser to seek again when the content was all played up or when the buffer was running low - things that should already be in place). This, to me, seems like an alternative to an addBytes method (if that does what I think it does). This would provide me with a strictly Javascript solution. Other methods I have been asking for would give me a purely HTTP solution (with new range related 4xxs and, spec endorsed, shorter than requested 206 responses) to achieve this or an HTML solution (using new video+source element attributes for buffer (min request size) and max request size).
Re: [whatwg] More YouTube response
On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Well this isnt really a list where we should talk about the dos and donts of web content distribution. DRM content can be embedded in the video tag and decoded using installable plugins so its not really an issue for this list I dont think. We cant dictate how the specs are used so try to keep the conversation technology neutral. Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have video in the first place. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] More YouTube response
On 02.07.2010 13:38, Anne van Kesteren wrote: On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Well this isnt really a list where we should talk about the dos and donts of web content distribution. DRM content can be embedded in the video tag and decoded using installable plugins so its not really an issue for this list I dont think. We cant dictate how the specs are used so try to keep the conversation technology neutral. Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have video in the first place. That may be true. But there's nothing in the spec that actually disallows adding support for plugin-based DRM, right? (Just clarifying) Best regards, Julian
Re: [whatwg] More YouTube response
On Fri, 2010-07-02 at 13:38 +0200, Anne van Kesteren wrote: On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Well this isnt really a list where we should talk about the dos and donts of web content distribution. DRM content can be embedded in the video tag and decoded using installable plugins so its not really an issue for this list I dont think. We cant dictate how the specs are used so try to keep the conversation technology neutral. Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have video in the first place. Well I got that from what Henri was saying. The reason why I said that was that we cant tell people how to use the spec. The video tag could be used for any kind of video be it a DRM video or non DRM .webm or .mp4 video, its really vendor preference on what they use. Shipping the DRM codec as a plugin will be a lot smaller and a lot easier than shipping the entire flash platform so it would be better than the current situation. I have to clarify that im against DRM anyway because not only does it not protect the content well in most cases but also most of it doesnt work on Linux by default. All im saying is that if youtube has a problem with html5 and want content protection through DRM then thats their decision. --fagan
Re: [whatwg] More YouTube response
If there were hooks for handling the bytes being requested and supplied to the media object, would you agree that DRM modules could be written with Javascript (if a bit of a straw man - as all DRM is perceived to varying degrees)? I think this could prevent the need for some plugins. On Fri, Jul 2, 2010 at 8:17 AM, Shane Fagan shanepatrickfa...@ubuntu.com wrote: On Fri, 2010-07-02 at 13:38 +0200, Anne van Kesteren wrote: On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Well this isnt really a list where we should talk about the dos and donts of web content distribution. DRM content can be embedded in the video tag and decoded using installable plugins so its not really an issue for this list I dont think. We cant dictate how the specs are used so try to keep the conversation technology neutral. Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have video in the first place. Well I got that from what Henri was saying. The reason why I said that was that we cant tell people how to use the spec. The video tag could be used for any kind of video be it a DRM video or non DRM .webm or .mp4 video, its really vendor preference on what they use. Shipping the DRM codec as a plugin will be a lot smaller and a lot easier than shipping the entire flash platform so it would be better than the current situation. I have to clarify that im against DRM anyway because not only does it not protect the content well in most cases but also most of it doesnt work on Linux by default. All im saying is that if youtube has a problem with html5 and want content protection through DRM then thats their decision. --fagan
Re: [whatwg] More YouTube response
On 2010-07-02 13:56, Julian Reschke wrote: On 02.07.2010 13:38, Anne van Kesteren wrote: On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Well this isnt really a list where we should talk about the dos and donts of web content distribution. DRM content can be embedded in the video tag and decoded using installable plugins so its not really an issue for this list I dont think. We cant dictate how the specs are used so try to keep the conversation technology neutral. Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have video in the first place. That may be true. But there's nothing in the spec that actually disallows adding support for plugin-based DRM, right? (Just clarifying) Correct. Vendors can theoretically implement any codec or container they like, with any features or limitations they like. MP4 already has various DRM schemes in use. Apple, for example, could support FairPlay protected videos, though the use of such content with video would effectively be limited to within iTunes. Even Matroska has elements that can be used for general purpose encryption and DRM purposes, though these features were not included within WebM. But theoretically, those features could be added and implemented with some agreed upon encryption scheme. I would still, however, argue against anything of the sort being added to WebM because DRM doesn't do anything to protect content, but is rather used as a way for content providers to control the market by blocking unwanted innovation and competition that they don't like, including open source software. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] More YouTube response
On Fri, Jul 2, 2010 at 5:50 AM, Lachlan Hunt lachlan.h...@lachy.id.auwrote: On 2010-07-02 13:56, Julian Reschke wrote: On 02.07.2010 13:38, Anne van Kesteren wrote: Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have video in the first place. That may be true. But there's nothing in the spec that actually disallows adding support for plugin-based DRM, right? (Just clarifying) Correct. Vendors can theoretically implement any codec or container they like, with any features or limitations they like. MP4 already has various DRM schemes in use. Apple, for example, could support FairPlay protected videos, though the use of such content with video would effectively be limited to within iTunes. Even Matroska has elements that can be used for general purpose encryption and DRM purposes, though these features were not included within WebM. But theoretically, those features could be added and implemented with some agreed upon encryption scheme. I would still, however, argue against anything of the sort being added to WebM because DRM doesn't do anything to protect content, but is rather used as a way for content providers to control the market by blocking unwanted innovation and competition that they don't like, including open source software. I think it's unavoidable that the functionality of the video tag in some browsers will be extended by various add-ons to the browser. IE's implementation uses whatever codecs are installed and available to DirectShow; my understanding is that Safari operates this way as well. My point here is primarily that it would be good for video tag adoption in general if browsers enabled traditional DRM solutions to integrate in this way. It still requires that users will have some non-open software installed on their machine (that's unavoidable as long as content owners require it of us), but means that users can continue using their browser of choice, and content distributors don't need to write a completely new player for each DRM provider they need to support.
Re: [whatwg] More YouTube response
On Fri, Jul 2, 2010 at 5:50 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2010-07-02 13:56, Julian Reschke wrote: On 02.07.2010 13:38, Anne van Kesteren wrote: On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Well this isnt really a list where we should talk about the dos and donts of web content distribution. DRM content can be embedded in the video tag and decoded using installable plugins so its not really an issue for this list I dont think. We cant dictate how the specs are used so try to keep the conversation technology neutral. Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have video in the first place. That may be true. But there's nothing in the spec that actually disallows adding support for plugin-based DRM, right? (Just clarifying) Correct. Vendors can theoretically implement any codec or container they like, with any features or limitations they like. MP4 already has various DRM schemes in use. Apple, for example, could support FairPlay protected videos, though the use of such content with video would effectively be limited to within iTunes. Even Matroska has elements that can be used for general purpose encryption and DRM purposes, though these features were not included within WebM. But theoretically, those features could be added and implemented with some agreed upon encryption scheme. I would still, however, argue against anything of the sort being added to WebM because DRM doesn't do anything to protect content, but is rather used as a way for content providers to control the market by blocking unwanted innovation and competition that they don't like, including open source software. Indeed. Also compare to the recent battle that was fought over font formats. Some parties where heavily pushing for DRM formats, however ultimately we were able to persuade them that this wasn't needed, and we ended up with a format that everyone is happy with. / Jonas
Re: [whatwg] More YouTube response
On Thu, Jul 1, 2010 at 9:16 PM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: As several people pointed out (and which I tried to get at in my post), this is really an ecosystem issue rather than a change needed in the spec or in browsers. I suspect it's going to take some time, but the flexibility of embedding content via iframe will be a big step forward. Wouldn't it be straightforward for YouTube to offer iframe support right now, in addition to object? The backend support should be simple to do. If you keep the object code as the default embed recommendation and hide the iframe embed code somewhere so people will only use it if they look for it, you won't risk confusing anyone. Sites that currently whitelist object from YouTube will eventually whitelist iframe from YouTube too -- I hope there aren't many sites that permit *arbitrary* objects to be inserted by untrusted users. Allowing iframe will have other benefits, like allowing fallback install Flash content (currently omitted from the object code, I assume to keep the size down). Yes, it's pretty straightforward to offer iframe-based embed code, but it needs to be coupled with getting sites to accept them, or we end up with a lot of confused, unhappy users. Note that sites don't generally whitelist specific SWFs - they generally allow all Flash embeds. Another thing that occurs to me is that you might show HTML5 video when Flash isn't installed/enabled, or when the Flash player crashes. Or at least you could give an option, instead of just failing silently (for embeds) or saying the user should install Flash (on the site itself). My primary machine runs Linux, and Flash usually doesn't work at all. If I didn't know about the HTML5 beta, I wouldn't be able to use YouTube at all. And as it is, I can't use any YouTube embeds most of the time. Yes, this is the main point of using an iframe to embed code - it allows the site providing embeddable content to tailor the presentation to the user/device/context at runtime, rather than requiring the presentation to be fixed up-front. When limiting keyboard input, I'd suggest devices w/ onscreen keyboards simply disable the keyboard. Applications that work well with touch interfaces generally provide gesture alternatives for the limited set of keys that would be available. Alternately, devices could limit the keyboard to the set of allowed keys. The problem is if the program makes a fake keyboard and then directly intercepts touch events to that location, without invoking the OS's keyboard at all. The user won't be able to tell that the keypresses are going to the website instead of the OS. But I can't see this as being a big issue -- screen space is so limited on these devices that websites are fullscreen anyway, or practically. On my Nexus One, unless you're scrolled to the top of the site, websites take up the whole screen except for the bar at the top, which is present in all apps. So they could already trivially spoof any application, if they know the target platform. Not if the user presses the menu button, I guess. Yeah, I realized that loophole after I sent the mail. The same vulnerability is there if fullscreen is initiated by a control the browser chrome, though - at the end of the day, the primary problem to solve is ensuring that users understand they're still viewing a web page, and the contents are provided by the web page rather than the OS. As pointed out, this is not strictly an issue for video tag, though certainly related especially for local preview. I have not been closely following the work on the device element, though that seems to be where this is headed. device adoption shouldn't interfere with video adoption, though. Even if YouTube switched to video by default, it could keep Flash for recording until device was implemented. It's probably best for implementers to focus on perfecting video (and maybe canvas, etc.) before they put too much work into device, since those are much bigger use-cases. You're absolutely right, and I think the order things are going is correct - video is more important than device
Re: [whatwg] More YouTube response
On 2010-07-02 21:01, John Harding wrote: On Fri, Jul 2, 2010 at 5:50 AM, Lachlan Huntlachlan.h...@lachy.id.auwrote: Correct. Vendors can theoretically implement any codec or container they like, with any features or limitations they like. MP4 already has various DRM schemes in use... I would still, however, argue against anything of the sort being added to WebM... I think it's unavoidable that the functionality of thevideo tag in some browsers will be extended by various add-ons to the browser. Right, as I said, it's possible. But that doesn't mean we should support it in any way. YouTube would do better to address this issue by bringing the major players in the content industry to the table to discuss methods of publishing their content in interoperable ways without DRM. As Henri pointed out, major content producers already broadcast their TV shows and movies over the air without DRM. Although the BBC iPlayer uses DRM for the desktop version, they broadcast the show DRM free over the air and they make DRM free content available to the iPhone. People have even found ways to access that from other devices too. So the DRM really isn't there to protect the content. It's just to force users to use the BBC's own iPlayer software, rather than letting users use their own choice of software. The industry even releases content on DVD knowing that the DRM is completely ineffective, because they only use it so they can control the DVD player market, rather than actually doing anything practical about illegal copying. The music industry have already largely dropped DRM. Even Spotify, which does use DRM, permits the open source application deSpotify that bypasses the DRM to continue unimpeded for premium subscribers. (The developers opted not to work around the blocks placed on free accounts though). It's all about the business model. The industry thinks they need their DRM so they can hold onto the same business model they've had for years, without adapting. That's why they've gone to court over every new innovation in the last 50 years, before slowly catching up. The truth is they don't need DRM, as so many independent content producers are demonstrating. YouTube and other video streaming sites just needs to push them to accept a reasonable and fair business model that will work. Make it easy for users to stream the content, and even easier for users who want to buy and download the content legally. Users currently go to torrent sites because it's easier than fighting with the industry to get what they want. Make it easier to do the right thing. Don't punish the legitimate them with DRM, while the pirates get away with a better user experience. Give users a real reason to buy, and they will. e.g. Make the purchased content have a higher bit-rate and resolution, surround sound, no ads, no visible logo watermark, and/or other added features. Provide some incentive, maybe a reward system that benefits the subscribers in some tangible way. Do whatever you do to find a business model that works; just say no to DRM. It's not needed. The big content industry knows that, they just won't admit it. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] More YouTube response
On Jul 2, 2010, at 12:09 PM, John Harding wrote: On Thu, Jul 1, 2010 at 9:16 PM, Aryeh Gregor simetrical+...@gmail.com wrote: As several people pointed out (and which I tried to get at in my post), this is really an ecosystem issue rather than a change needed in the spec or in browsers. I suspect it's going to take some time, but the flexibility of embedding content via iframe will be a big step forward. Wouldn't it be straightforward for YouTube to offer iframe support right now, in addition to object? The backend support should be simple to do. If you keep the object code as the default embed recommendation and hide the iframe embed code somewhere so people will only use it if they look for it, you won't risk confusing anyone. Sites that currently whitelist object from YouTube will eventually whitelist iframe from YouTube too -- I hope there aren't many sites that permit *arbitrary* objects to be inserted by untrusted users. Allowing iframe will have other benefits, like allowing fallback install Flash content (currently omitted from the object code, I assume to keep the size down). Yes, it's pretty straightforward to offer iframe-based embed code, but it needs to be coupled with getting sites to accept them, or we end up with a lot of confused, unhappy users. Note that sites don't generally whitelist specific SWFs - they generally allow all Flash embeds. Any site which does that has a giant security hole, since Flash can be used to arbitrarily script the embedding page. It's about as safe as allowing embedding of arbitrary off-site script. If you are aware of sites that allow embedding of arbitrary off-site Flash, you should alert them to the potential security risks. For example a social network site that allowed this would be vulnerable to a self-propagating worm. What I have heard before is that sites whitelist specific SWFs or Flash from specific domains. I'm don't have any first-hand knowledge of how sites actually do it. Regards, Maciej
Re: [whatwg] More YouTube response
On Jul 2, 2010, at 6:04 PM, Maciej Stachowiak wrote: Any site which does that has a giant security hole, since Flash can be used to arbitrarily script the embedding page. It's about as safe as allowing embedding of arbitrary off-site script. If you are aware of sites that allow embedding of arbitrary off-site Flash, you should alert them to the potential security risks. For example a social network site that allowed this would be vulnerable to a self-propagating worm. What I have heard before is that sites whitelist specific SWFs or Flash from specific domains. I'm don't have any first-hand knowledge of how sites actually do it. With testing I found at least one site where I can apparently embed arbitrary SWFs. However, this site has per-user domains, so it might be relatively safe. This site also allows me to embed arbitrary content in an iframe. Regards, Maciej
[whatwg] More YouTube response
Glad to see my post spurred some good discussion - I'll try to address topic by topic below, but one of the great points made is that some of the functionality YouTube needs from browsers probably doesn't belong in the HTML5 spec (e.g. streaming, content protection). I'm happy to take those discussions elsewhere if this forum is inappropriate, but it seems like it would likely be the same group of people, just on a different mailing list. 1. Standard Video Format Yes, this has been debated a lot, and I generally agree that leaving it out of the spec was the best way forward for the spec. Shane Fagan pointed out that Flash supports multiple different codecs, which is true, but every version since Flash 7 has supported Sorenson Spark video and MP3 audio. I don't think anyone is suggesting that browsers shouldn't support multiple codecs, but having a consistent baseline is important. On the current path, a content provider knows that by offering H.264 and WebM, they can reach all HTML5-capable browsers. This honestly is a reasonable state for YouTube right now - we use H.264 in cases outside the video tag as well, but it would be nice to converge on a single baseline format at some point in the future. 2. Robust Video Streaming Andy Berkheimer on our team has been putting some thought into this, so I'll defer to him for more specific proposals. For an app like YouTube, it is *extremely *useful to have fine-grained control over how the browser fetches media from the server. Whether the details belong in the HTML5 spec or not depends on the preferred design - something similar to Flash 10.1's appendBytes() mechanism would affect the video tag interface, for example, while a transport protocol could be completely separate. 3. Content Protection Some of the discussion here seems to have conflated application-controlled video delivery with content protection, but in an ideal world, the two are independent. The basic requirements around content protection that we get from content owners basically consist of encrypting the content and limiting the decryption to a verified and authorized client - the realm of traditional DRM. Rather than ask browsers to get into the DRM business, what I think would work best is having a means for 3rd party DRM providers to supply browser plug-ins which implement the video tag for protected content - not all that different than selecting a pluggable codec. 4. Encapsulation and Embedding As several people pointed out (and which I tried to get at in my post), this is really an ecosystem issue rather than a change needed in the spec or in browsers. I suspect it's going to take some time, but the flexibility of embedding content via iframe will be a big step forward. 5. Fullscreen Maciej actually covered YouTube's requirements pretty well. I'd add that it's not just controls that are important for us to maintain: we have a lot of additional content that needs to display with and sometimes on top of the video - our interactive annotations, captions, and ads most notably. Maciej's proposal also looks fairly reasonable, though some thoughts on it: When limiting keyboard input, I'd suggest devices w/ onscreen keyboards simply disable the keyboard. Applications that work well with touch interfaces generally provide gesture alternatives for the limited set of keys that would be available. Alternately, devices could limit the keyboard to the set of allowed keys. Keyboard restrictions are better than not having fullscreen support, though they do limit functionality - it would prevent us from supporting search in fullscreen mode, for example. 6. Camera and Micrphone access As pointed out, this is not strictly an issue for video tag, though certainly related especially for local preview. I have not been closely following the work on the device element, though that seems to be where this is headed. -John
Re: [whatwg] More YouTube response
On Thu, Jul 1, 2010 at 6:59 PM, John Harding jhard...@google.com wrote: Some of the discussion here seems to have conflated application-controlled video delivery with content protection, but in an ideal world, the two are independent. The basic requirements around content protection that we get from content owners basically consist of encrypting the content and limiting the decryption to a verified and authorized client - the realm of traditional DRM. Rather than ask browsers to get into the DRM business, what I think would work best is having a means for 3rd party DRM providers to supply browser plug-ins which implement the video tag for protected content - not all that different than selecting a pluggable codec. I suspect that it would be best to just leave this use-case to Flash. It would be basically impossible to get the kind of obfuscation that content owners will want via open standards, because people will just implement clients that skip the obfuscation. So you're pretty much stuck with nonstandard plugins anyway. This decision could be revisited if there's still a lot of demand for this once the basic non-DRM use-cases are covered. As several people pointed out (and which I tried to get at in my post), this is really an ecosystem issue rather than a change needed in the spec or in browsers. I suspect it's going to take some time, but the flexibility of embedding content via iframe will be a big step forward. Wouldn't it be straightforward for YouTube to offer iframe support right now, in addition to object? The backend support should be simple to do. If you keep the object code as the default embed recommendation and hide the iframe embed code somewhere so people will only use it if they look for it, you won't risk confusing anyone. Sites that currently whitelist object from YouTube will eventually whitelist iframe from YouTube too -- I hope there aren't many sites that permit *arbitrary* objects to be inserted by untrusted users. Allowing iframe will have other benefits, like allowing fallback install Flash content (currently omitted from the object code, I assume to keep the size down). Another thing that occurs to me is that you might show HTML5 video when Flash isn't installed/enabled, or when the Flash player crashes. Or at least you could give an option, instead of just failing silently (for embeds) or saying the user should install Flash (on the site itself). My primary machine runs Linux, and Flash usually doesn't work at all. If I didn't know about the HTML5 beta, I wouldn't be able to use YouTube at all. And as it is, I can't use any YouTube embeds most of the time. When limiting keyboard input, I'd suggest devices w/ onscreen keyboards simply disable the keyboard. Applications that work well with touch interfaces generally provide gesture alternatives for the limited set of keys that would be available. Alternately, devices could limit the keyboard to the set of allowed keys. The problem is if the program makes a fake keyboard and then directly intercepts touch events to that location, without invoking the OS's keyboard at all. The user won't be able to tell that the keypresses are going to the website instead of the OS. But I can't see this as being a big issue -- screen space is so limited on these devices that websites are fullscreen anyway, or practically. On my Nexus One, unless you're scrolled to the top of the site, websites take up the whole screen except for the bar at the top, which is present in all apps. So they could already trivially spoof any application, if they know the target platform. Not if the user presses the menu button, I guess. As pointed out, this is not strictly an issue for video tag, though certainly related especially for local preview. I have not been closely following the work on the device element, though that seems to be where this is headed. device adoption shouldn't interfere with video adoption, though. Even if YouTube switched to video by default, it could keep Flash for recording until device was implemented. It's probably best for implementers to focus on perfecting video (and maybe canvas, etc.) before they put too much work into device, since those are much bigger use-cases.
