W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2010

[whatwg] [ogg-dev] HTML5 audio tag

From: Chris Pearce <chris@pearce.org.nz>
Date: Wed, 12 May 2010 12:19:36 +1200
Message-ID: <4BE9F418.7080906@pearce.org.nz>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:23 UTC