Re: MPEG-2 TS Closed Caption mapping

On Wed, May 28, 2014 at 10:43 PM, Bob Lund <B.Lund@cablelabs.com> wrote:
>
>
>> -----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?

There's more to a new feature in the browser than just the on-screen
rendering, e.g. event handling, timing, synchronisation. Even if we
just restrict it to rendering, is the CEA708 spec so accurate that two
implementations come up with pixel-identical renderings? That is
important to achieve for testing of compliance of different
implementations. If so, then at least rendering is taken care of,
which would be a win.

Cheers,
Silvia.

Received on Sunday, 1 June 2014 03:34:12 UTC