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

So you *are* exposing the track to JS - but without cues? You are
expecting the browser to react to JS changing the track @mode.

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? How is that going to fit into the browser rendering loop
and the browser coodinate system? You're going to need a spec.


>> 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 Monday, 26 May 2014 13:44:18 UTC