Re: how does EME/DRM effect captioning

On Tue, Apr 2, 2013 at 7:45 PM, Henri Sivonen <hsivonen@iki.fi> wrote:

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

The conversion spec is actually at:
https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html

Rollup behaviour has been made part of the 21st Century Communications and
Video Accessibility Act through the FCC regulations created by the CVAA.
We've had in-depth discussions about this in the Text Track Community Group
and a good summary can be found at
http://lists.w3.org/Archives/Public/public-texttracks/2012Dec/0066.html .


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

I'd actually be curious about this as well, because I've heard people state
that captions are just as valuable and as much "content" as the video
itself, in their own right. So, I'm curious to hear whether people expect
to send their captions also in encrypted form when they distribute
encrypted content or whether they're happy to provide them in the clear
through a <track> element.

Cheers,
Silvia.