- From: Chris Pearce <chris@pearce.org.nz>
- Date: Wed, 12 May 2010 12:19:36 +1200
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.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100512/c419d545/attachment-0001.htm>
Received on Tuesday, 11 May 2010 17:19:36 UTC