Re: EME and timed text

On Wed, Apr 3, 2013 at 4:00 AM, Henri Sivonen <hsivonen@iki.fi> wrote:

> So this WG should consider captions and subtitles to be outside the
> DRM realm, because of the Netflix precedent.
>

No.


> It's a mistake to think that the W3C should grant DRM to whoever says
> they want it.


No. The W3C is in no position to grant anything or deny anything. The W3C
publishes specs. That's 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.


No. Clever content providers can find ways to do DRM on about any content.


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

And then?


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

Capitulates? The W3C doesn't control the uses of the Web or the Internet.


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


Which is outside the scope of EME.


> 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 one possibility among many. Though it wouldn't be the CDM, but
something to which the CDM delegates decoding with tacit approval by the
UA's media implementation.


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

No.


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

Who is suggesting they be DRMable for principle's sake? You are reading
many things into this thread that just don't exist in anyone's mind.