Re: Temporal fragments of media with time stamps

SMPTE timecodes are actually just labels on frames (see
http://en.wikipedia.org/wiki/SMPTE_time_code). Thus, in a linear, live
streaming file, they will be contiguous (even though when using
drop-frame, there will be a missing code sometimes). Addressing on
such files will be no different to npt time addressing.

A problem only occurs when an edited video that retains the original
time codes on each picture is addressed.

This is realistically not a problem in digital files such as we are
dealing with. As far as I know, modern video editors will, as the
finished video is exported, either drop time code tracks or write a
new consistent time code track. At worst, the time codes were burnt
into the original video stream and cannot be removed anyway, but these
will not be relevant to a software system anyway.

So, our use case for SMPTE is really only for material with a
contiguous time code, which is either original unedited material or
material with a newly written time code. In cases where that is not
the case, the UA or the server have to read the time codes and deliver
what they think the intention of the URI was, e.g. if a request from
0h-10m-0s to 0h-20m-0s appears, it delivers whatever it has in between
these markers, even if there is a gap of 5 min. You can simply not
rely on duration calculation by subtracting labels, cause that's all
they are: labels. In this way, SMPTE is actually more like id
addressing that like time addressing.

To be honest: I don't think that SMPTE markers will be used for media
fragment addressing much anyway. We had SMPTE addressing functionality
for Annodex for 10 years and nobody used it. So, I don't think we need
to worry too much about it.

BTW: that most timecodes start at 10 hours is I think because of the
analog tapes where they originated. If you didn't have a 1 at the
beginning, you didn't know whether the tape's timecode had even been
initialised.

Cheers,
Silvia.


On Tue, Jan 19, 2010 at 6:48 PM, David Singer <singer@apple.com> wrote:
> SMPTE time-codes are actually embedded in the media.  They might be continuous in a media file, they might not be.
>
> For example, a fragment request for SMPTE 0h-10m-0s to 0h-20m-0s might appear to be a 10 minute clip starting 20 minutes in, but
> a) if the first time code in the file is in fact 0h-5m-0s, it's only 15 minutes into the clip (and indeed, TV time-codes typically treat 10h as the start time, I have no idea why)
> b) if there is a discontinuity in the time-codes such that 0h-15m-59s is followed by 0h-18m-0s, then it's only an 8 minute cli[p that's requested, in fact.
>
> On Jan 19, 2010, at 16:23 , Davy Van Deursen wrote:
>
>>> -----Original Message-----
>>> From: public-media-fragment-request@w3.org [mailto:public-media-
>>> fragment-request@w3.org] On Behalf Of David Singer
>>> Sent: maandag 18 januari 2010 2:38
>>> To: Jack Jansen
>>> Cc: Davy Van Deursen; 'Bailer, Werner'; public-media-fragment@w3.org;
>>> 'Richard Wright-ARCHIVES'
>>> Subject: Re: Temporal fragments of media with time stamps
>>>
>>>
>>> On Jan 18, 2010, at 8:06 , Jack Jansen wrote:
>>>
>>>>
>>>> On 16 jan 2010, at 10:25, Davy Van Deursen wrote:
>>>>>
>>>>> Temporal fragments should indeed take into account embedded time
>>> stamps.
>>>
>>> 'may', I think, surely.  It depends on whether the fragment time is
>>> expressed in NPT, or (say) SMPTE time-codes.  NPT starts at 0;  to
>>> resolve a fragment here, you're fine without inspecting the media.
>>>
>>> SMPTE time-codes, OTOH, need to be found.  They might not even be
>>> continuous in the media.
>>
>> Hmm, what do you mean by 'need to be found'? Suppose an MP4 file starting
>> with an empty edit of 20s, followed by 40s video. What is the meaning of
>> t=npt:0,30 and t=smpte:00:00:00:00,00:00:30:00? IMO, they will both result
>> in an MP4 file starting with an empty edit of 20s, followed by 10s, no?
>>
>> Best regards,
>>
>> Davy
>>
>> --
>> Davy Van Deursen
>>
>> Ghent University - IBBT
>> Department of Electronics and Information Systems - Multimedia Lab
>> URL: http://multimedialab.elis.ugent.be/dvdeurse
>>
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
>
>

Received on Tuesday, 26 January 2010 06:28:08 UTC