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
[whatwg] Iframe dimensions
Hello I found that the dimensions of the iframe element are handled along with those of other embedded content such as img, video and others: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#attr-dim-width There is no indication about what a UA should do when dimension attributes are not specified. UAs do seem to handle this case differently for those elements: To an img element, they apply the actual pixel dimensions of the image file, while they seem to apply default dimensions to iframe elements. But there are some special indications in the part about the @seamless attribute: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-seamless quote o In visual media, in a CSS-supporting user agent: the user agent should set the intrinsic width of the iframe to the width that the element would have if it was a non-replaced block-level element with 'width: auto'. o In visual media, in a CSS-supporting user agent: the user agent should set the intrinsic height of the iframe to the height of the bounding box around the content rendered in the iframe at its current width (as given in the previous bullet point), as it would be if the scrolling position was such that the top of the viewport for the content rendered in the iframe was aligned with the origin of that content's canvas. /quote First, this sounds somehow complicated to me, and second, I don't understand why the dimensions of non-seamless iframes should not get the benefits of author-friendly (and user-friendly) dimension handling. I want to suggest to provide a way to make an iframe behave just like any block element regarding width and height, that means: If no dimensions are specified, use the full available width, and apply the height needed to display the full content. Use case: Some content from an external specialized content provider is included in an existing web site via an iframe. This cannot be seamless, as the links in the iframe must point to the original domain of the included document. But in order to avoid double scroll bars, it would be desirable to have the height of the iframe adjusted to it's content. Example: http://test.rapid.ch/de/haendler-schweiz/iseki.html (This is under construction.) As a workaround to the height problem, I applied a script that adjusts the iframe height to the available height in the browser window. But of course the user experience would be more consistent if the page could behave like a single page, with only one scrollbar at the right of the browser window. Possible solutions: - Invent an attribute that makes the iframe element behave like any block element (independent from @seamless) - Respect the CSS display property; display:block would then make an iframe rendered like a block element While I personally would be happy with the second solution, I have no idea if this can be specced in HTML5, as it is CSS. And AFAICS the CSS specs do not cover individual HTML elements. I'd be happy about some comments!
Re: [whatwg] Iframe dimensions
On Mon, Jul 5, 2010 at 10:13 AM, Markus Ernst derer...@gmx.ch wrote: First, this sounds somehow complicated to me, and second, I don't understand why the dimensions of non-seamless iframes should not get the benefits of author-friendly (and user-friendly) dimension handling. One of the reasons is security: if we automatically sized iframes, an attacker could learn things about documents in other origins. Another reason is compatibility: changing how frames layout would likely break the layout of a large number of web sites. Adam
Re: [whatwg] Iframe dimensions
Am 05.07.2010 19:24 schrieb Adam Barth: On Mon, Jul 5, 2010 at 10:13 AM, Markus Ernst derer...@gmx.ch wrote: First, this sounds somehow complicated to me, and second, I don't understand why the dimensions of non-seamless iframes should not get the benefits of author-friendly (and user-friendly) dimension handling. One of the reasons is security: if we automatically sized iframes, an attacker could learn things about documents in other origins. I can't imagine how the information about the computed width and height can be abused - would you mind giving an example? A possible workaround to security issues could be an element to be set in the included document, such as a meta tag that contains a comma separated list of domains that are allowed to include the document, and also get informations about dimensions and such. Some kind of: meta name=allow-embedding content=whatwg.org, mozilla.com Also, if this is a potential danger, should the 2 list paragraphs about width and height in the part on @seamless be removed at all? As far as I understand, the effects of @seamless require the iframe source to be from the same origin as the parent document, thus I think that width and height of an iframe should be computed independent from @seamless. Else, the whole page layout is likely to change if the iframe source is navigated from a same-origin document to one from another origin. Another reason is compatibility: changing how frames layout would likely break the layout of a large number of web sites. I don't think the 2 solutions I proposed would do any BC harm: - Inventing a new attribute does not affect legacy browsers (as they will ignore it), nor legacy pages (as they don't have it). - Interpreting the CSS declaration display:block as the author's wish to get the iframe rendered like a block element is nothing but consistent. There has been no reason for authors to apply this declaration so far, but if anyone did, he/she wanted the rendering I suggest. If not (for example if the iframe is floating), he/she also applied dimensions, be it in the HTML or the CSS code.
Re: [whatwg] proposal - link relations: rel=prefetch to be exchanged for a boolean attribute
On Sun, Jul 4, 2010 at 10:41 PM, Ben Schwarz ben.schw...@gmail.com wrote: However, as far as my understanding goes, linkrels should not contain multiple values; eg: a rel=prefetch nextNext page/a They can. See the spec: The types of link indicated (the relationships) are given by the value of the rel attribute, which, if present, must have a value that is a set of space-separated tokens. http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-link-rel It's allowed to have multiple types separated by spaces. This is common in some cases, like rel=alternate stylesheet.
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] Iframe dimensions
On Mon, Jul 5, 2010 at 1:13 PM, Markus Ernst derer...@gmx.ch wrote: Some content from an external specialized content provider is included in an existing web site via an iframe. This cannot be seamless, as the links in the iframe must point to the original domain of the included document. But in order to avoid double scroll bars, it would be desirable to have the height of the iframe adjusted to it's content. This use-case is inherently insecure. An iframe's height cannot depend on the contents of a cross-origin page unless that origin explicitly opts in somehow. I found that the dimensions of the iframe element are handled along with those of other embedded content such as img, video and others: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#attr-dim-width There is no indication about what a UA should do when dimension attributes are not specified. I can't find it either. If it's really not specced anywhere, that's a bug that should be fixed. On Mon, Jul 5, 2010 at 3:37 PM, Markus Ernst derer...@gmx.ch wrote: I can't imagine how the information about the computed width and height can be abused - would you mind giving an example? For a basic example, suppose that a page on some site is reliably a different height depending on whether you're logged in or not (this is usually true). Then when you visit my site, I could create a hidden iframe with the other site inside, and measure the height from JavaScript. Then I'd know whether you're logged in on that site. There are lots of other conditions that would change the height of a page, and they could leak a large amount of information to arbitrary third-party sites. No site should be able to find out anything about your use of another site, to the extent possible. A possible workaround to security issues could be an element to be set in the included document, such as a meta tag that contains a comma separated list of domains that are allowed to include the document, and also get informations about dimensions and such. Some kind of: meta name=allow-embedding content=whatwg.org, mozilla.com This could be handled by seamless using CORS or whatever, sure. Also, if this is a potential danger, should the 2 list paragraphs about width and height in the part on @seamless be removed at all? As far as I understand, the effects of @seamless require the iframe source to be from the same origin as the parent document, thus I think that width and height of an iframe should be computed independent from @seamless. Else, the whole page layout is likely to change if the iframe source is navigated from a same-origin document to one from another origin. You're correct: if you navigate the iframe to a different origin, the iframe will no longer be seamless, and all the effects of seamless will cease to apply. This means it will change height and width, CSS rules won't apply, etc., etc. The presence of seamless= does definitely change the width and height computations, and many other things. I don't think the 2 solutions I proposed would do any BC harm: - Inventing a new attribute does not affect legacy browsers (as they will ignore it), nor legacy pages (as they don't have it). Yes, this is why the seamless attribute works. - Interpreting the CSS declaration display:block as the author's wish to get the iframe rendered like a block element is nothing but consistent. There has been no reason for authors to apply this declaration so far, but if anyone did, he/she wanted the rendering I suggest. If not (for example if the iframe is floating), he/she also applied dimensions, be it in the HTML or the CSS code. The author might or might not originally have wanted the behavior you said, but in the end, the site doesn't render that way, and changing the rendering like that would make the site look very different from the way it looked before (= the final product that the author was satisfied with and released).
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] Iframe dimensions
On 7/5/10 12:37 PM, Markus Ernst wrote: I can't imagine how the information about the computed width and height can be abused - would you mind giving an example? Sure. For example, you can often use this to detect whether the user is currently logged into the site in the iframe, which is a privacy leak. Depending on the target site, other things that might be exposed this way are things like the number of credit card transactions the user has performed in the last month, the number of phone calls the user has made in the last month... you get the idea. A possible workaround to security issues could be an element to be set in the included document, such as a meta tag that contains a comma separated list of domains that are allowed to include the document, and also get informations about dimensions and such. Some kind of: meta name=allow-embedding content=whatwg.org, mozilla.com How is this different from allowing opt-in into seamless iframes across origins? Also, if this is a potential danger, should the 2 list paragraphs about width and height in the part on @seamless be removed at all? As far as I understand, the effects of @seamless require the iframe source to be from the same origin as the parent document, thus I think that width and height of an iframe should be computed independent from @seamless. Else, the whole page layout is likely to change if the iframe source is navigated from a same-origin document to one from another origin. Yes, it will. Why is this a problem? There has been no reason for authors to apply this declaration so far, but if anyone did, he/she wanted the rendering I suggest. Experience shows this to not be the case. People blindly apply CSS without thinking through the implications as long as the current rendering is right; I will bet money there are pages out there that use display:block on iframes just to get linebreaks before/after and will break if the sizing behavior changes. -Boris
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/
