Re: how does EME/DRM effect captioning

On Thu, Mar 28, 2013 at 7:01 PM, Glenn Adams <glenn@skynav.com> wrote:
> There are different sets of requirements (in the U.S.) pertaining to content
> providers and content presentation devices (e.g., a device containing a UA
> that is presenting content). Of course there is no requirement that captions
> be DRMed and I did not suggest otherwise. Nor did I suggest that a browser
> must be responsible for presenting unaccessible caption content. What I did
> say is that CDM vendors may be obligated to expose captions to the UA in
> plain text form under some circumstances, and it would be the responsibility
> of the manufacturer of a regulated device to make use of that content as
> regulation requires.

Can you point to a U.S. regulation that leads to the conclusion that
if a content provider attempts to deliver DRMed captions to a Web
browser and the browser has a CDM that can deal with video and audio
DRM for what's being delivered, the CDM is obligated to provide the
clear text of the captions to the browser as opposed to the compliance
remedy being that the content provider stop applying DRM to the
captions?

I heard the point that in the MPEG-2 case CEA-708 data goes inside the
video track for the purpose of track division in a container, so if
DRM is applied to the video track, it gets applied to 708 captions,
too. Since MPEG-2 is not in any way either technically or legally a
reasonable contender for a Web video codec, I think the W3C should
ignore the MPEG-2 case as inapplicable and focus on how stuff works
with CENC/H.264/AAC and WebM/VP8/Vorbis.

If a TV broadcaster has content that has been broadcast using TV
technology with 608 or 708 captions, I think the reasonable way to
comply with the FCC regulation that requires that content to come with
captions when delivered on the Internet is to convert the 608/708
captions to non-DRMed WebVTT when they convert the MPEG-2 video to
H.264 or VP8. There is even an extension spec for WebVTT that's
motivated by enabling full-fidelity conversion of 608/708 captioning
for compliance with the relevant regulation:
https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/region.html
(I haven't seen an explanation why a conversion would have to retain
the rollup behavior in order to comply with the regulation, though.)

>> If CDMs and browsers don't support DRMed captions (my reading of the
>> Chromium source code suggests that Chrome with Widevine doesn't and to
>> me that looks like a very reasonable decision), the way content
>> providers can meet the regulatory requirements is that they provide a
>> non-DRMed WebVTT captions to be rendered by the browser without the
>> involvement of the CDM.
>
> Sure, providing unencrypted captions in TTML or WebVTT is an option, as is
> providing either or both of these in addition to captions embedded in an
> encrypted video stream.
>
> Are you saying something new here that I didn't already say or suggest?

Yes. I pointed out that the source code of the browser that has
actually shipped EME indicates that that browser does not support CDM
participation in captioning. Hence, handling captions outside the DRM
realm is the scenario that has to be used in practice considering what
has actually shipped.

(Again, this is based on my inspection of the Chromium source code.
Chrome developers, please correct me if I'm wrong.)

--
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 2 April 2013 08:46:24 UTC