Re: [whatwg] [ogg-dev] HTML5 audio tag
Yeah, the track attribute of the media fragments specification that Ralph links will in theory allow to just download the track-related data. But it still requires implementation - either in the browser, which will somehow need to identify which bytes belong to which track and just request those byte ranges that are relevant, or on the server, which will only deliver the relevant bytes when asked for the audio track only. None of this is implemented yet. In fact, the discovery of which bytes in a Ogg stream belong to which track is a challenge. I am not sure whether the new Skeleton Index format might actually allow for that... Cheers, Silvia. On Wed, May 12, 2010 at 3:32 AM, Frank Barchard fbarch...@google.com wrote: FWIW chromium does client side range requests that in theory would request only the audio. But. the ogg demux reads the other tracks and discards them. A use case I've heard is listening to music videos and discard the video... bit of a bandwidth waste. On Tue, May 11, 2010 at 10:17 AM, Ralph Giles gi...@thaumas.net wrote: On 11 May 2010 04:24, narendra sisodiya narendra.sisod...@gmail.com wrote: It will be very good if HTML5 API specify this. I mean, Say, If we use audio tag , then It must stream only audio part of the file irrespective of the fact that the src field contains a video file. I don't think that's a practical option, since the server must manipulate the file to return an audio-only subset of the data for there to be any bandwidth advantage. That's not something that the HTML5 specification, which documents browser behaviour, can describe. Note that it's completely possible to use a server-size module or script to do this, using a query url in the HTML5 media element's src attribute. It's just part of a custom server config rather than the HTML5 API. The Media Fragments Working Group at the W3C is currently working on a standardized syntax for this. See http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/ if you're interested. FWIW, -r ___ ogg-dev mailing list ogg-...@xiph.org http://lists.xiph.org/mailman/listinfo/ogg-dev ___ ogg-dev mailing list ogg-...@xiph.org http://lists.xiph.org/mailman/listinfo/ogg-dev
Re: [whatwg] [ogg-dev] HTML5 audio tag
In order to do this you'd need to know /in advance/ exactly which Ogg pages were audio and which were video so you could choose to only download the vorbis pages. The upcoming Ogg Skeleton index does not index pages at a high enough granularity to facilitate this. It could, but then the index would be a lot bigger. I also wonder if the time/server overhead of setting up new HTTP byte-range request for each ~4KB Ogg vorbis page wouldn't make this worth while. Especially over a high latency connection. You'd be best to oggz-rip the streams you want out in advance and serving them statically, as Conrad suggested. It's /impossible/ to determine in advance which byte ranges to download in order to download only one stream. You simply don't know which stream a page belongs to or what size it is until you've downloaded the page. Chris P. On 12/05/2010 11:18 a.m., Silvia Pfeiffer wrote: Yeah, the track attribute of the media fragments specification that Ralph links will in theory allow to just download the track-related data. But it still requires implementation - either in the browser, which will somehow need to identify which bytes belong to which track and just request those byte ranges that are relevant, or on the server, which will only deliver the relevant bytes when asked for the audio track only. None of this is implemented yet. In fact, the discovery of which bytes in a Ogg stream belong to which track is a challenge. I am not sure whether the new Skeleton Index format might actually allow for that... Cheers, Silvia. On Wed, May 12, 2010 at 3:32 AM, Frank Barchardfbarch...@google.com wrote: FWIW chromium does client side range requests that in theory would request only the audio. But. the ogg demux reads the other tracks and discards them. A use case I've heard is listening to music videos and discard the video... bit of a bandwidth waste. On Tue, May 11, 2010 at 10:17 AM, Ralph Gilesgi...@thaumas.net wrote: On 11 May 2010 04:24, narendra sisodiyanarendra.sisod...@gmail.com wrote: It will be very good if HTML5 API specify this. I mean, Say, If we use audio tag , then It must stream only audio part of the file irrespective of the fact that the src field contains a video file. I don't think that's a practical option, since the server must manipulate the file to return an audio-only subset of the data for there to be any bandwidth advantage. That's not something that the HTML5 specification, which documents browser behaviour, can describe. Note that it's completely possible to use a server-size module or script to do this, using a query url in the HTML5 media element's src attribute. It's just part of a custom server config rather than the HTML5 API. The Media Fragments Working Group at the W3C is currently working on a standardized syntax for this. See http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/ if you're interested. FWIW, -r ___ ogg-dev mailing list ogg-...@xiph.org http://lists.xiph.org/mailman/listinfo/ogg-dev ___ ogg-dev mailing list ogg-...@xiph.org http://lists.xiph.org/mailman/listinfo/ogg-dev
Re: [whatwg] [ogg-dev] HTML5 audio tag
I've heard it is easier with MP4 to do byte-range requests for a track only. Thanks for clarifying that index won't have any of this information! Indeed, providing an audio file on the server is the simplest solution to this (follow the KISS-principle :). Cheers, Silvia. On Wed, May 12, 2010 at 10:19 AM, Chris Pearce ch...@pearce.org.nz wrote: In order to do this you'd need to know in advance exactly which Ogg pages were audio and which were video so you could choose to only download the vorbis pages. The upcoming Ogg Skeleton index does not index pages at a high enough granularity to facilitate this. It could, but then the index would be a lot bigger. I also wonder if the time/server overhead of setting up new HTTP byte-range request for each ~4KB Ogg vorbis page wouldn't make this worth while. Especially over a high latency connection. You'd be best to oggz-rip the streams you want out in advance and serving them statically, as Conrad suggested. It's impossible to determine in advance which byte ranges to download in order to download only one stream. You simply don't know which stream a page belongs to or what size it is until you've downloaded the page. Chris P. On 12/05/2010 11:18 a.m., Silvia Pfeiffer wrote: Yeah, the track attribute of the media fragments specification that Ralph links will in theory allow to just download the track-related data. But it still requires implementation - either in the browser, which will somehow need to identify which bytes belong to which track and just request those byte ranges that are relevant, or on the server, which will only deliver the relevant bytes when asked for the audio track only. None of this is implemented yet. In fact, the discovery of which bytes in a Ogg stream belong to which track is a challenge. I am not sure whether the new Skeleton Index format might actually allow for that... Cheers, Silvia. On Wed, May 12, 2010 at 3:32 AM, Frank Barchard fbarch...@google.com wrote: FWIW chromium does client side range requests that in theory would request only the audio. But. the ogg demux reads the other tracks and discards them. A use case I've heard is listening to music videos and discard the video... bit of a bandwidth waste. On Tue, May 11, 2010 at 10:17 AM, Ralph Giles gi...@thaumas.net wrote: On 11 May 2010 04:24, narendra sisodiya narendra.sisod...@gmail.com wrote: It will be very good if HTML5 API specify this. I mean, Say, If we use audio tag , then It must stream only audio part of the file irrespective of the fact that the src field contains a video file. I don't think that's a practical option, since the server must manipulate the file to return an audio-only subset of the data for there to be any bandwidth advantage. That's not something that the HTML5 specification, which documents browser behaviour, can describe. Note that it's completely possible to use a server-size module or script to do this, using a query url in the HTML5 media element's src attribute. It's just part of a custom server config rather than the HTML5 API. The Media Fragments Working Group at the W3C is currently working on a standardized syntax for this. See http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/ if you're interested. FWIW, -r ___ ogg-dev mailing list ogg-...@xiph.org http://lists.xiph.org/mailman/listinfo/ogg-dev ___ ogg-dev mailing list ogg-...@xiph.org http://lists.xiph.org/mailman/listinfo/ogg-dev
Re: [whatwg] OGG in HTML5
On 11 Dec 2007, at 16:20, alex wrote: I am a webdeveloper and a fierce supporter of opensource. I was under the impression the standards were being designed in the same opensource spirit, but I may have been wrong. Standards are developed inline with the policies of the organisations they are developed by. http://www.w3.org/Consortium/Process/ describes the W3C process document. The issue here is that the chairs think the reasons given for not publishing a working draft are strong enough (i.e., it is the strength of the arguments, not the number in favour of the arguments that is important). Setting OGG as the de facto standard is the best idea i've heard in a long time, How can you set a de-facto standard? By the very meaning of de-facto, you cannot. We can set a de-jure standard, but not a de-facto one. and now it's all coming down because a few companies (some of which are known for their vendor lock-in tactics) want to keep their empire. No, it is coming down because a few companies don't want to take the risk of being sued for submarine patents which might exist for Ogg/ Vorbis/Theora. Do you want to pick up the bill for patent infringement? MS has to pay 1.52 billion USD for (submarine) patent infringement covering MP3. Unsurprisingly, major companies don't want to take such a risk on a codec that has few advantages over current standards such as MPEG-4. But why, then, are they happy to support MPEG standards? They already do: it had/has clear technical advantages to prior de-facto formats (the same cannot be said for Theora, which is less efficient than MPEG-4). They have already taken the risk to support it, and people have already had the chance to sue them, and that has not yet happened. In the case of MS and Apple, they already support video formats at the OS level, and don't re-implement them within the browser (and have already therefore paid patent charges). Finally, the risk of supporting both is greater than supporting just one. There are already widespread de-facto standards, so that is what they will choose to support, not a container/codec combination that has (comparatively) very little content. I am not saying that ogg should be enforced onto anyone, if nokia wishes to keep using a different format, no problem, but by making it a standard, we at least know that ogg will be supported by all (standards-compatible) browsers, and as such it can be deployed by those who are opposed to vendor lock-in or monopoly positions. It won't be supported by all (currently) standards-compatible browsers. Apple, a major browser vendor, has said they don't intend to implement Ogg/Vorbis/Theora just because the spec requires it (i.e., if you can get a critical mass of web content using it, you may well be able to get them to support it). OGG is the choice of freedom, enabling that freedom for all webdevelopers is a must in my opinion, although in the same spirit, it can not be enforced upon anyone, therefor the original text stating it should instead of it must is probably the best way to go. If it is a MUST, then the spec is irrelevant: it will be ignored by major companies. We must settle at a compromise between the two POVs to get the spec implemented at all; we otherwise run the risk of major companies not implementing any part of the spec whatsoever, leaving us far worse off that we would be otherwise. Also, if it a MUST everyone in the WG would be issuing a RF license covering any patents they hold covering Ogg/Vorbis/Theora to everyone else in the WG (as per http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential ), which companies such as MS and Nokia have said they are unwilling to do. As far as compromises go, there are several viable solutions, including MJPEG and H.261 (the latter is only slightly worse than Theora, and is so old (as of next year, even the revision to it will be 20 years old) that any and all patents have either expired or are invalid). This still leaves questions open regarding container format and audio (which I know less about, and won't comment so much on). If you truly do want make no compromises yourself, you may be able to get the major browser manufacturers that are currently unwilling to implement Ogg/Vorbis/Theora to implement them by getting a critical mass of content out there. Bear in mind, though, that MS still does not support MPEG-4 out of the box (except for Zune), despite the huge amount of MPEG-4 content already out there. -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] OGG in HTML5
2007/12/11, alex [EMAIL PROTECTED]: I am a webdeveloper and a fierce supporter of opensource. I was under the impression the standards were being designed in the same opensource spirit, but I may have been wrong. Setting OGG as the de facto standard is the best idea i've heard in a long time, and now it's all coming down because a few companies (some of which are known for their vendor lock-in tactics) want to keep their empire. I am not saying that ogg should be enforced onto anyone, if nokia wishes to keep using a different format, no problem, but by making it a standard, we at least know that ogg will be supported by all (standards-compatible) browsers, and as such it can be deployed by those who are opposed to vendor lock-in or monopoly positions. well, I think that ENFORCING is the way the real life works, is the case of windows, it is used because the hardware vendors enforce us to use it installing it by default, is the case of the mp3, is the case of any file format, is the case of swf, and is the case of wma, people use all that crap because they are enforced, I think is very positive that when we create something, if it is pretty useful we have the power to enforce is use, for the good, and is ok, HTML5 should enforce OGG as a supported format, IT IS GOOD FOR EVERYONE, only look at what happened with the PNG, is now wide accepted over GIF. OGG is the choice of freedom, enabling that freedom for all webdevelopers is a must in my opinion, although in the same spirit, it can not be enforced upon anyone, therefor the original text stating it should instead of it must is probably the best way to go. Freedom for those who choose, the alternative for the rest. --
