Re: how does EME/DRM effect captioning

On Tue, Apr 2, 2013 at 2:45 AM, 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?
>

You are reading into my comments conclusions that I did not imply. I said
that CDM vendors *may* need to expose captions depending on local
regulatory requirements. I'm not prepared to provide you citations of all
local regulatory requirements. It is up to manufacturers of regulated
devices to do their own research and reach their own conclusions.


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

The W3C should not ignore real word use cases. And delivery via MPEG-2 is a
real-world use case.


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


Sure, that's one choice. There are others as well.


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

Currently shipping EME prototypes have no necessary bearing on what is
eventually required or shipped. EME has not even been published as a FPWD
and you are already trying to lock-in behavior of prototypes? Really?!
Anyone that ships a feature before it has reached REC bears the risk of
having to change their implementation as the specification matures.