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.

Received on Tuesday, 25 March 2014 08:26:14 UTC