- From: Bob Lund <B.Lund@CableLabs.com>
- Date: Wed, 28 May 2014 12:43:50 +0000
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- CC: Eric Winkelman <E.Winkelman@cablelabs.com>, "Ladd, Pat" <Pat_Ladd2@cable.comcast.com>, "Clift, Graham" <Graham.Clift@am.sony.com>, "public-inbandtracks@w3.org" <public-inbandtracks@w3.org>
> -----Original Message----- > From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com] > Sent: Tuesday, May 27, 2014 5:39 PM > To: Bob Lund > Cc: Eric Winkelman; Ladd, Pat; Clift, Graham; public-inbandtracks@w3.org > Subject: Re: MPEG-2 TS Closed Caption mapping > > On Wed, May 28, 2014 at 12:06 AM, Bob Lund <B.Lund@cablelabs.com> > wrote: > > > > > >> -----Original Message----- > >> From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com] > >> Sent: Monday, May 26, 2014 7:44 AM > >> To: Bob Lund > >> Cc: Ladd, Pat; Clift, Graham; public-inbandtracks@w3.org > >> Subject: Re: MPEG-2 TS Closed Caption mapping > >> > >> On Tue, May 20, 2014 at 12:48 AM, Bob Lund <B.Lund@cablelabs.com> > >> wrote: > >> > > >> > > >> > On 5/18/14, 8:31 PM, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> > wrote: > >> > > >> >>On Wed, May 14, 2014 at 11:26 PM, Bob Lund <B.Lund@cablelabs.com> > >> wrote: > >> >>> > >> >>> > >> >>>> -----Original Message----- > >> >>>> From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com] > >> >>>> Sent: Wednesday, May 14, 2014 3:19 AM > >> >>>> To: Ladd, Pat > >> >>>> Cc: Clift, Graham; Bob Lund; public-inbandtracks@w3.org > >> >>>> Subject: Re: MPEG-2 TS Closed Caption mapping > >> >>>> > >> >>>> On Tue, May 13, 2014 at 7:13 AM, Ladd, Pat > >> >>>> <Pat_Ladd2@cable.comcast.com> wrote: > >> >>>> > Graham; > >> >>>> > > >> >>>> > I took a different meaning from your question. In > >> >>>> > >> > >>>>http://rawgit.com/silviapfeiffer/HTMLSourcingInbandTracks/master/ > >> >>>>in > >> d > >> >>>>ex.h tml section 3, the table in step 3 indicates that when a > >> >>>>Caption Service Descriptor is signaled in a PMT a TextTrack is > >> >>>>created with kind "captions" and in the case of captions > >> >>>>digitized in the video stream, i.e. CEA708, the id is the PID of > >> >>>>the video elementary stream carrying the captions. > >> >>>> > >> >>>> Correct. > >> >>>> > >> >>>> > What I gather from that is setting the captions TextTrack > >> >>>> > mode to > >> >>>>showing > >> >>>> will cause the captions in the video stream to be rendered. > >> >>>> > >> >>>> Incorrect. They can only be rendered by the browser if the > >> >>>>browser understands the caption format. For example, WebM has > >> >>>>captions in WebVTT format - they will be exposed as a TextTrack > >> >>>>with VTTCue captions and thus follow the WebVTT rendering spec. > >> >>>>If your captions come from a > >> >>>> MPEG4 file in a CEA708 track, a TextTrack can be created, but > >> >>>>the captions cannot be exposed in a renderable form, since there > >> >>>>is no TextTrackCue format for CEA708. > >> >>> > >> >>> If the captions are to be rendered ONLY by the UA then it would > >> >>>seem there is no need to define a cue format. It would be > >> >>>implementation dependent how the UA formats caption data for > rendering. > >> >> > >> >>Are you thinking of a situation where browsers will render caption > >> >>tracks, but not expose them to the JS API? > >> > > >> > Yes. > >> > > >> >> In this situation, how does > >> >>the Web developer know that there is a caption track visible? > >> > > >> > A caption text track will be created. The app can check the mode of > >> > that track. If Œshowing¹ then the UA is rendering the captions. If > >> > hidden, then the UA is not rendering. > > > > Yes > > > >> > >> So you *are* exposing the track to JS - but without cues? You are > >> expecting the browser to react to JS changing the track @mode. > > > > Yes > > > >> > >> You are expecting it to render CEA708 cues when this empty track is > >> made 'showing'. But you are not expecting to write a spec for > >> browsers for how to do the rendering? Are you expecting them to > >> implement a > >> CEA708 spec? > > > > Yes > > > > >How is that going to fit into the browser rendering loop and the > >> browser coodinate system? You're going to need a spec. > > > > Why isn't this an UA implementation issue? The reference implementation > we did created WebVTT cues from the raw 708 captions data. > > Because if you leave it to the browsers to decide how to support CEA708, > every browser will come up with a different solution. The CEA708 spec defines how an implementation renders 708 captions. Existing rendering devices (mostly TVs) use it. Why would a UA (for UA rendered captions) need another spec? > > Silvia.
Received on Wednesday, 28 May 2014 12:44:23 UTC