W3C home > Mailing lists > Public > public-media-fragment@w3.org > November 2008

Byte ranges and time ranges

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 11 Nov 2008 17:40:44 +1100
Message-ID: <2c0e02830811102240y3a6d80efpac6bb01bf6867ba2@mail.gmail.com>
To: "Media Fragment" <public-media-fragment@w3.org>

Hi everybody,

I have to report this to you - this is too interesting a piece of
information to miss.

I have just had a chat with Chris Double who is implementing the Ogg
theora video tag support for HTML5 into Firefox. He explains how they
are right now using byte range requests to gain access to subparts of
Ogg Thera during playback, when people jump directly to time offsets.

This is how it works:

Say the following video element is given:
<video src="http://example.com/random.ogv"/>

Then people click at 30sec offset in the transport bar, which causes
the following javascript to be executed:
document.getElementsByTagName("video")[0].currentTime=30

Assuming that part of the file had not been downloaded, what happens
is as follows:

* the request goes from the browser to liboggplay
* liboggplay makes an educated guess at the byte offset that relates
to this time offset based on the file size and the average bitrate of
the file (which were received as first information about the video)
* liboggplay hands back the byte ranges to the browser
* the browser makes a read request on these byte ranges via http
(using these functions
http://hg.mozilla.org/mozilla-central/file/5dfdad637696/content/media/video/src/nsMediaStream.cpp)
* the server returns those byte ranges and the browser hands them back
to liboggplay, which determines from the received granulepositions
what time they relate to
* if the requested time is not hit, liboggplay makes a better estimate
on byte ranges and another http byte range request is sent, etc. until
the right byte ranges are returned

This is amazingly the exact same seeking algorithm that is used by
media players that seek to time offsets in Ogg file. The only
difference is that the seeking algorithm is now implemented over HTTP
rather than local file I/O. If the guesses are good, less than 10
round trips are necessary, Chris says. He also says that the delay
introduced through these roundtrips are barely visible in the browser.
He has tested with Wikimedia and other content and it works reliably.

Chris also says that if he can get a cooperative server which can do
the time-byte-mapping that we are discussion, he'd rather use the
seeking support on the server. However, I find it amazing that it is
working so well even without such server support!

I think we can draw some conclusions from this:

* when loading up a video, a couple of roundtrips don't make much of a
difference; thinking about this further, I actually think this is the
case because we are used to Web pages that take a long time to load
because they have to download many resources and cannot get them all
in parallel; we are also used to videos sitting in the browser
buffering because the bandwidth is not big enough; in comparison two
roundtrips for video are really nothing

* asking for byte ranges alone can work.


Cheers,
Silvia.
Received on Tuesday, 11 November 2008 06:41:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:31 GMT