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 <giles at thaumas.net> wrote:> On 11 May 2010 04:24, narendra sisodiya <narendra.sisodiya at 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-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/ogg-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/ogg-dev/attachments/20100511/759d0e71/attachment.htm
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 <fbarchard at 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 <giles at thaumas.net> wrote: >> >> On 11 May 2010 04:24, narendra sisodiya <narendra.sisodiya at 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-dev at xiph.org >> http://lists.xiph.org/mailman/listinfo/ogg-dev > > > _______________________________________________ > ogg-dev mailing list > ogg-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/ogg-dev > >
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<fbarchard at 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<giles at thaumas.net> wrote: >> >>> On 11 May 2010 04:24, narendra sisodiya<narendra.sisodiya at 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-dev at xiph.org >>> http://lists.xiph.org/mailman/listinfo/ogg-dev >>> >> >> _______________________________________________ >> ogg-dev mailing list >> ogg-dev at xiph.org >> http://lists.xiph.org/mailman/listinfo/ogg-dev >> >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/ogg-dev/attachments/20100512/c419d545/attachment.htm