- From: Silvia Pfeiffer <silvia@silvia-pfeiffer.de>
- Date: Wed, 12 May 2010 10:43:07 +1000
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 <chris at 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 <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 > > > > > >
Received on Tuesday, 11 May 2010 17:43:07 UTC