- From: Bob Lund <B.Lund@CableLabs.com>
- Date: Mon, 24 Mar 2014 21:22:47 +0000
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- CC: "Clift, Graham" <Graham.Clift@am.sony.com>, Brendan Long <B.Long@cablelabs.com>, "public-inbandtracks@w3.org" <public-inbandtracks@w3.org>
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? > >Silvia.
Received on Monday, 24 March 2014 21:23:22 UTC