- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 3 Apr 2013 13:00:18 +0300
- 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