- From: Jack Jansen <Jack.Jansen@cwi.nl>
- Date: Wed, 25 Mar 2009 22:05:27 +0100
- To: Media Fragment <public-media-fragment@w3.org>
- Message-Id: <734EDB25-93AA-4958-A645-802363626606@cwi.nl>
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 timecode=15.0s. 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 addressing. -- 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 Wednesday, 25 March 2009 21:06:12 UTC