W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2008

[whatwg] media elements: Relative seeking

From: Eric Carlson <eric.carlson@apple.com>
Date: Mon, 01 Dec 2008 20:51:39 -0800
Message-ID: <F3DA3F63-B775-46CF-9699-E293390CC290@apple.com>

On Dec 1, 2008, at 6:10 PM, Chris Double wrote:

>  The only accurate value I can provide with Ogg is the exact  
> duration if the http server supports byte range requests, or some  
> other out of band duration metadata (X-Content-Duration, etc).  
> Without byte range requests, accurate duration is not possible.
>
   While you can seek to the end of an Ogg file to get duration from  
the last frame's time stamp, you can't do that with every file type.

   For example, an MPEG audio elementary stream (eg. MP3) isn't a file  
format, it is just the raw output from a decoder, and there are no  
time stamps at all so the only way to get an accurate file duration is  
to sum the duration of every sample. It is *possible* to include an  
indication of duration in the file [1][2], but a player must be  
prepared to handle files without any indication as well as files in  
which the stored duration(s) are inconsistent with the observed  
duration.

   As I have noted before, an estimated duration based on the  
calculated duration of the portion(s) of a file that have been  
processed, iteratively refined as more data is seen, works well for  
us. You might try it with files on servers that don't support byte  
range requests, or on machines where you don't want to incur the cost  
of extra network IO.

eric

[1] VBR files can include a header with the number of MPEG audio  
frames in the file. This can be used with the sampling rate to  
calculate the duration.

[2] Some ID3v2 tags include a frame that stores the file duration in  
milliseconds (strangely enough, stored as a string).
Received on Monday, 1 December 2008 20:51:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:46 UTC