W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2007

[whatwg] <video> element feedback

From: Maik Merten <maikmerten@gmx.net>
Date: Sat, 24 Mar 2007 20:19:21 +0100
Message-ID: <460579B9.301@gmx.net>
Geoffrey Sneddon schrieb:
> That sort of info is held within the container, so everything within Ogg
> (so both Theora and Dirac) will suffer from it. H.264 being part of the
> MPEG-4 standard follows what Kevin Marks said:
> On 24 Mar 2007, at 08:57, Kevin Marks wrote:
>> 2. define a chunk/offset table that maps media to time, and look this
>> up ahead of any seeking. (this is the QT approach, and that of MPEG4

Well, with Ogg you can just fetch a bit of the start (seems that's
needed for MPEG, too - I just killed a few bytes from the beginning of a
.mp4 files and it won't play) and get an educated guess about bitrate
etc. to directly jump to a position in the file (you there get a precise
timestamp). If you ended up jumping too far away from the destination
you can repeat once or twice and you're "close" enough.

That has been done before, works like a charm.
http://stream.fluendo.com/demos.php?stream=ondemand (that's a Java Ogg
Theora streaming applet)

I can see the value of having a direct seek table, but omitting that has
it's nice sides, too: You can just concatenate two Ogg files and you
directly have a valid Ogg stream again. That's used extensively with
playlist streaming (e.g. using the Icecast server) and is pretty popular.

In worst case it should be easily possible to define a simple format for
an external jumping table that can be fetched by the user agent
(video.ogg.idx or whatever) or even embed that in another logical stream
at the beginning of an Ogg file.
Received on Saturday, 24 March 2007 12:19:21 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:54 UTC