RE: MPEG-2 TS Closed Caption mapping



> -----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.

> 
> 
> >> This is
> >>as "bad" as burnt-in captions
> >
> > Not sure what you mean by Œas bad as¹.
> 
> JS and Web pages have no access to the text that was the origin of burnt-in
> captions. You're replicating this situation when you don't expose captions as
> cues. It makes it impossible to use the text, e.g.
> for search index building and thus disallows direct access to time offsets in
> videos with relevant content.
> 
> 
> >> and would better be exposed to the
> >>browser API in that way: as a video track with burnt-in captions (a
> >>VideoTrack with VideoTrack.kind="captions"). There would be no need to
> >>expose any text track for this.
> >
> > AFAICT, there is no kind for burned in captions, which might be
> > main-captions?
> 
> Yes there is. See:
> http://www.w3.org/html/wg/drafts/html/master/embedded-

> content.html#dom-videotrack-kind
> . A kind of "captions" on a video track signifies burnt-in captions.
> Text tracks with rendered captions but no cues are indeed better exposed as
> video tracks of kind="cpations".
> 
> Cheers,
> Silvia.

Received on Tuesday, 27 May 2014 14:07:37 UTC