Re: MPEG-2 TS metadata cue guidelines

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.

Silvia.

Received on Monday, 24 March 2014 20:45:06 UTC