W3C home > Mailing lists > Public > public-media-fragment@w3.org > March 2009

Timecodes that are not zero-based

From: Jack Jansen <Jack.Jansen@cwi.nl>
Date: Wed, 25 Mar 2009 22:05:27 +0100
Message-Id: <734EDB25-93AA-4958-A645-802363626606@cwi.nl>
To: Media Fragment <public-media-fragment@w3.org>
There's another issue I ran into while implementing. I seem to  
remember that we've discussed it, but I'm not sure I remember the  
outcome of the discussion correctly. So here goes. Please let me know  
whether the following statement is correct.

If the original media starts at a timecode that is not zero, we still  
treat it as such for addressing. In other words, if the first frame of  
a video has timecode=10.0s and we request a clip with t=5, the first  
frame we receive will be 5 seconds into the clip, and hence have  

Correct, so far?

This leads to two inconveniences in the implementation that I think we  
need to spell out in the spec:

1. If the client gets more data that requested (for example, starting  
at timecode=12.0s in the example above, because that's the closest I- 
frame) that client cannot look at timecodes to find the correct frame  
to start playback. The client code should first calculate the amount  
of time to skip, using the range data returned by the server and the  
fragment specified in the URL, then convert that to a timestamp (using  
the timestamp of the first frame).
2. Frame-accurate addressing for non-zero-based smpte-30-drop  
timecodes is hairy: as the "timecode-space" of the original media and  
the timecode-space of the URL are different we should probably  
consider that both these spaces have the inserted timecodes at the  
expected locations. That would seem to be the only consistent  
specification. Unfortunately, it is probably also exactly what the  
user did not intend.

We could solve the last issue by saying "don't do this": we only  
guarantee frame-accuracy if both of the following conditions hold: (a)  
the timecode type used in the fragment specifier is identical to the  
timecode type used in the original media, and (b) the original media  
starts with timecode 00:00:00:00.

Alternatively, we could somehow extend the syntax to allow not only  
zero-based fragment addressing but also media-timebase-based fragment  
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  

Received on Wednesday, 25 March 2009 21:06:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:42 UTC