Re: Temporal fragments of media with time stamps

On 18 jan 2010, at 11:54, Yves Lafon wrote:

>> 
>> If I have a video http://www.example.com/example.mp4, which has 10 seconds worth of video, with timestamps 01:00:00:00 through 01:00:10:00, and a UA sends a request
>> with
>> 	Range: t:smpte=01:00:05:00-01:00:06:00
>> what does it get back in the Content-Range header?
>> I would assume the timestamps are as expected, but what is the duration returned?
> 
> The duration should be the duration of the complete file, so 10s in this case. The fact that 10s and range is starting well over 10s is an indicator that the offset is not zero. Now... do we need to send the starting offset as well? (and if so using what kind of syntax).


Hmm.

If this is the correct answer, then I'm not sure what the point is of sending the duration in the first place. With byte content ranges it's clear that this is a cheap way to provide some extra information to the client ("I'm sending you bytes 100 thru 200, and the whole file is 1000 bytes long"). This can potentially enable the client to refrain from doing requests that would be out-of-range anyway. Same for npt-based content ranges (assuming these will work with a "0s means begin-of-file" semantic). A duration would only be useful if the client already knows the begin timestamp through an out-of-band method, but then the question is why the end timestamp isn't also transmitted through this same out-of-band channel.

I think we either need to send begin/end timestamps, or nothing at all. I _think_ my preference would be nothing at all (but that preference could change at very short notice:-), because it may be expensive to find the correct values (may need to seek to begin/end of stream), and it may even be impossible (live stream). Moreover, I would say that the value of these values to the client is probably not so great (less than for npt or byte ranges).
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman

Received on Monday, 18 January 2010 22:18:58 UTC