Re: MPEG-2 TS metadata cue guidelines

After discussing the latest proposal internally, I¡¯m OK with startTime = 0
and endTime = video.currentTime equivalent of PTS cue in the media
resource. As discussed, pause_on_exit = false.

Bob

On 3/25/14, 7:19 AM, "Bob Lund" <B.Lund@CableLabs.com> wrote:

>
>________________________________________
>From: Silvia Pfeiffer [silviapfeiffer1@gmail.com]
>Sent: Tuesday, March 25, 2014 2:25 AM
>To: Bob Lund
>Cc: Clift, Graham; Brendan Long; public-inbandtracks@w3.org
>Subject: Re: MPEG-2 TS metadata cue guidelines
>
>On Tue, Mar 25, 2014 at 8:22 AM, Bob Lund <B.Lund@cablelabs.com> wrote:
>>
>>
>> On 3/24/14, 2:44 PM, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
>>wrote:
>>
>>>On Tue, Mar 25, 2014 at 7:37 AM, Bob Lund <B.Lund@cablelabs.com> wrote:
>>>>
>>>> From: <Clift>, Graham <Graham.Clift@am.sony.com>
>>>> Date: Monday, March 24, 2014 at 10:11 AM
>>>> To: Brendan Long <B.Long@cablelabs.com>, Bob Lund
>>>><b.lund@cablelabs.com>,
>>>> "public-inbandtracks@w3.org" <public-inbandtracks@w3.org>
>>>> Subject: RE: MPEG-2 TS metadata cue guidelines
>>>>
>>>>
>>>>
>>>> I have one suggestion. Instead of playing around with arbitrary
>>>>endtimes
>>>> why not set the starttime to the currentTime of playback when the cue
>>>>is
>>>> created (making it immediately active when created) and set the
>>>>endtime
>>>>to
>>>> the media resource time
>>>>
>>>>
>>>>
>>>> What is 'media resource time'?
>>>>
>>>> [<Graham>] Well that is terminology you use in the mapping spec. It is
>>>>the
>>>> time of the metadata with respect to the MPEG-2 TS timeline (eg PTS)
>>>>clock.
>>>> The startTime in contrast would be the HTML5 Media Element currentTime
>>>>when
>>>> the cue is created in UA, which is equivalent to
>>>>
>>>>                 startTime = endTime - (UA decoder buffering time) + UA
>>>>cue
>>>> generation processing time
>>>>
>>>>
>>>>
>>>> Why not endTime = startTime + 250msec? Seems easier.
>>>>
>>>> [<Graham>]
>>>>
>>>> I explained the reasoning but I will reiterate. 250msec is just some
>>>> arbitrary number. Rather than an arbitrary number why not just have
>>>>the
>>>> startTime before the mediaresource time to allow the application to
>>>>prepare
>>>> for the cue onexit event?
>>>>
>>>>
>>>> Is the following another way of stating your proposal?
>>>>
>>>> Let PTS0 be the the MPEG-2 TS PTS corresponding to video.currentTime =
>>>>0.
>>>> Let PTS1 be the MPEG-2 TS PTS of the video stream when the UA is ready
>>>>to
>>>> create a metadata text track cue from an associated elementary stream.
>>>>The
>>>> UA sets cue.startTime = video.currentTime and cue.endTime =
>>>>max(250msec,
>>>> PTS1 - PTS0).
>>>>
>>>
>>>
>>>Using video.currentTime for the startTime is not a good idea: every
>>>time you run the same file, you potentially get a different cue. This
>>>can't be tested consistently.
>>
>> The cues are in-band with a fixed relationship to the media resource©ös
>> timeline. With respect to a given cue, why would currentTime be
>>different
>> each time the  stream is received by the UA?
>
>video.currentTime is whatever time the video playback is showing at
>the particular time that the browser sees the metadata elementary
>stream. Since that happens while buffering the video data and since
>the video is likely to be playing, video.currentTime could be anything
>between 0 and PTS1. So, the startTime of such a cue would likely be
>not reproducable.
>
>Silvia.
>
><Bob> Setting all cue startTimes to 0 seems wrong.
>
>The fact is that there is only 1 time for MPEG-2 TS inband metadata cues
>that the UA knows about - the PTS corresponding to that cues data. This
>could be the startTime, in which case the endTime should be some delta
>greater than that. Or, this could be the endTime in which startTime
>should be some delta less than that.
>
>I prefer setting startTime to  the PTS and endTime to PTS + delta.
>
></Bob>
>
>

Received on Tuesday, 25 March 2014 19:02:23 UTC