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

[whatwg] [ogg-dev] HTML5 audio tag

From: Silvia Pfeiffer <silvia@silvia-pfeiffer.de>
Date: Wed, 12 May 2010 10:43:07 +1000
Message-ID: <AANLkTinBYYG1yrnv4VpIqORjC2opDGcClOvgLCzpE6vg@mail.gmail.com>
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

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