W3C home > Mailing lists > Public > public-media-fragment@w3.org > January 2010

Re: Temporal fragments of media with time stamps

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 27 Jan 2010 09:49:49 +1100
Message-ID: <2c0e02831001261449j749d6f25offbc3da3e9696787@mail.gmail.com>
To: David Singer <singer@apple.com>
Cc: Davy Van Deursen <davy.vandeursen@ugent.be>, "Bailer, Werner" <werner.bailer@joanneum.at>, public-media-fragment@w3.org, Richard Wright-ARCHIVES <richard.wright@bbc.co.uk>, Jack Jansen <Jack.Jansen@cwi.nl>
Or at least only when they are continuously increasing - gaps
shouldn't be too much of a problem.

On Wed, Jan 27, 2010 at 12:32 AM, David Singer <singer@apple.com> wrote:
> I agree it's unusual, but it is possible.  perhaps it's OK to say that you can only use systems like SMPTE time codes when they are, in fact, continuous in the file.
>
>
> On Jan 26, 2010, at 7:27 , Silvia Pfeiffer wrote:
>
>> 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.
>>>
>>>
>>>
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
>
Received on Tuesday, 26 January 2010 22:50:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:36 GMT