W3C home > Mailing lists > Public > public-html-media@w3.org > April 2013

Re: EME and timed text

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 3 Apr 2013 13:00:18 +0300
Message-ID: <CAJQvAuc_u6fyT3agJ+L0qS=chk2ucHfF1oft2o5OLEqMuqEJHw@mail.gmail.com>
To: David Singer <singer@apple.com>
Cc: Pierre-Anthony Lemieux <pal@sandflow.com>, "<public-html-media@w3.org>" <public-html-media@w3.org>
On Tue, Apr 2, 2013 at 7:44 PM, David Singer <singer@apple.com> wrote:
> On Apr 2, 2013, at 7:50 , Pierre-Anthony Lemieux <pal@sandflow.com> wrote:
>
>> Couple of thoughts on EME and timed text following up on our last call.
>>
>> - requirements for captions can be different from other kinds of timed
>> text, e.g. subtitles and karaoke. I am not convinced the possibility
>> of encrypted timed text can be excluded.

In the other thread, we heard that Comcast and Netflix don't need DRM
for captions. Netflix has subtitles in the Nordic markets. I'd be
highly surprised if the technical implementation wasn't identical to
captions. If Netflix can already do captions and subtitles without DRM
for content from major Hollywood studios, it doesn't seem plausible
that other services would decide not to compete with Netflix unless
there was DRM on captions or subtitles. The way this works is that you
don't get to demand DRM after someone with more "high value" content
of the same kind has already served that kind of content without DRM.
So this WG should consider captions and subtitles to be outside the
DRM realm, because of the Netflix precedent.

It's a mistake to think that the W3C should grant DRM to whoever says
they want it. Remember that the Web offers no DRM on photos or text
and if someone decides to keep their content off the Web for that
reason, it's their loss and the Web continues to do just fine. The
only reason to even entertain the thought of doing DRM for video is
that in the case of Hollywood movies, there's a concentration of
copyright holdership in a difficult to substitute body of content that
users crave unusually badly so that access or non-access to that
content becomes a non-trivial competitive advantage or disadvantage
for technology platforms and the copyright holders for that content
have for extended periods of time shown willingness to refrain from
competing with each other on reducing the hindrances to the access to
the content.

Even if the W3C capitulates to Hollywood and punches a new hole of
intentional non-interoperability to the Web platform just when the old
one (plug-ins) is going away, it shouldn't follow that that the W3C
should then start capitulating to karaoke.

>> - the (proposed) MPEG Part 30 allows carriage of timed text (WebVTT
>> and TTML) as part of the media data. Shouldn't EME apply in that case?
>> If not why? If yes, the following note in EME probably needs to be
>> revised: "Q: Can I encrypt captions / <track> elements? A: No, this
>> proposal only supports decrypting audio and video that are part of the
>> media data."
>
> I rather think it should say that it only supports decrypting the media data that's delivered, perhaps?  If there is a timed text track in the (say) MP4 file, why wouldn't the EME and MSE just work?

It depends on the interface between the CDM and the browser. If the
CDM is there only to protect keys and hands the decrypted content to
the browser, it might seem arbitrary not to let the CDM decrypt text
tracks. However, there's a slippery slope towards the kind of CDM
that's more likely for video tracks. The likely design for video is
that the CDM also handles decoding. That's a fairly contained
operation that can even be packaged as a hardware function. Not so
with decoding text tracks. For that, you need to let the CDM read and
rasterize fonts, which broadens the scope of the CDM considerably and
makes it potentially require more sandboxing entitlements in the
software case and putting a font subsystem in a hardware CDM makes
even less sense.

Text tracks just aren't equivalent with video tracks either
technically or in terms of the market consequences of not letting them
be DRMed. Timed text should not be DRMable just for principled
symmetry with video and audio.

--
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Wednesday, 3 April 2013 10:00:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:35 UTC