Re: Timecodes that are not zero-based

Hi Jack,

On Thu, Mar 26, 2009 at 8:05 AM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
> 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?

Yes and no. We said it would be up to the user agent to decide what
makes sense for itself. So, if you want to deal with the full context,
you do what you describe.

If you don't want to make users aware of the original context of the
extract, you can associate any timeline to it, e.g. in a mash-up or
edited version of a video, your user agent may internally hold the
urls to a list of videos from different sites, but display to the user
one linear timeline over all of them, if they so choose.

However, I think your described approach would be the default on.

> 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).

In Annodex/Ogg Skeleton we deal with this situation by having it
included in the header of the delivered file. It will say that it
starts for offset 12s, but that the display time should be 15s. This
will make the video decoder skip the beginning and display 15s as the
first timestamp.

Other formats probably do not support this approach yet, and then your
user agent will indeed need to do this manually as described.


> 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

I'd say "may be different". In your case, you're dealing with a
smpte-25 encoded video but addressing with smpte-30-drop, right?

> 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.

I spoke to the SMPTE guys at the time that we did Annodex about these
things. They regard their time codes simply as markers for specific
time offsets. These would not map onto a specific frame when the video
is not actually encoded with the related sampling rate.

So, you are correct: we can only guarantee frame-accuracy when the
encoding matches the timecode specifier. In all other cases we can
only do an approximation.

However, I think we can still deal with the non-zero-based fragment
addressing in the same way that we deal with it in your above example
that uses npt.

What we are doing in Annodex is: we convert a smpte timecode
specification to a npt time and then do all the offset calculations in
npt/seconds. You can see my time handling for CMML in
http://svn.annodex.net/libcmml/trunk/src/cmml_time.c .

Hope this helps?

Cheers,
Silvia.

Received on Friday, 27 March 2009 20:57:09 UTC