Re: how does EME/DRM effect captioning

You guys got a little off-topic here and there is some ambiguity about
whether you mean MPEG-2 Transport Streams (which can carry H.264) or MPEG-2
Video below. I think the former.

They are adding support for carriage of timed text in the ISO File Format
as well. So we have the situation that whatever file format you choose (ISO
or MPEG-2 TS), technically there could be captions embedded in the
encrypted media. They are only now working on a common encryption format
for MPEG2-TS, though, so until that is specified, developed and deployed
you lose the huge advantage of being DRM-agnostic if you use encrypted
MPEG-2 TS.

For our part we use the ISO File Format for all our streaming to recent
models (past few years) of TVs and Set Top Boxes and to Android phones and
desktop browsers. It works just fine on those devices. There are some other
kinds of device which only support MPEG-2 TS though.

However, we deliver captions/subtitles separately in a (unencrypted) TTML
file.

Whilst Glenn is right that some HTML5 implementations on TVs and Set Top
Boxes support MPEG-2 TS, there is no reason at all for this to be used for
modern adaptive streaming in the Internet. The argument about legacy
content is specious, since content has to be re-encoded anyway for the web,
for adaptive streaming. The ISO file format is far more suitable for this
purpose. You only have to look at the years of discussion that it took
during the MPEG DASH group to figure out how to squeeze MPEG-2 TS into an
adaptive streaming model, or the similar eyes-of-needles that the MPEG-2 TS
camel is being squeezed through in the MSE work.

So I would see no good reason to deliver captions/subtitles in encrypted
form unless the license terms for those requires it. The argument that "we
have this legacy encrypted MPEG 2 TS stream containing captions and we
can't do anything to pull out the captions" doesn't hold much water, IMO.

As to whether licensing terms for captions/subtitles require encryption, I
can't predict the future, but we don't have any in our service today that
do (and we do have captions/subtitles - that isn't a clever statement about
nothing ;-)

...Mark


On Wed, Apr 3, 2013 at 4:19 AM, Glenn Adams <glenn@skynav.com> wrote:

>
> On Wed, Apr 3, 2013 at 5:05 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
>
>> On Wed, Apr 3, 2013 at 1:32 PM, Glenn Adams <glenn@skynav.com> wrote:
>> > On Wed, Apr 3, 2013 at 4:18 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
>> >> On Tue, Apr 2, 2013 at 7:24 PM, Glenn Adams <glenn@skynav.com> wrote:
>> >> > 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:
>>
>> >> Which browsers currently implement MPEG-2 without DRM in HTML5 video?
>> >
>> > Hmm, let's see, there are Samsung Smart TVs, LG TVs, Sony TVs, .... I'm
>> not
>> > sure where the list stops.
>>
>> Thanks. Do you happen to know how recently these TV makers added HTML5
>> video support to the embedded browsers? Do they also support H.264?
>>
>
> The process of adding HTML5 support is ongoing. DLNA is very active in
> this process. In general, they do also support H.264, but device
> manufacturers don't control what is transmitted. Content service providers
> tend to lag behind technology standards due the large amount of investment
> in infrastructure, edge caching and so on. Even if content service
> providers wish to transition to a new code, e.g., H.264, that is a multi
> year process. Perhaps as long as a decade.
>
>
>>
>> >> Which content providers currently serve MPEG-2 in an HTML5-based
>> >> player?
>> >
>> > Every commercial video service provider I am familiar with.
>>
>> Which ones are you familiar with? Does Netflix stream MPEG-2 to
>> devices that can do H.264? (Seems unlikely.)
>>
>
> I can't answer for Netflix. But if a content provider has the ability to
> send content in H.264 and the device supports it, then it is likely that
> will be used rather than MPEG-2.
>
>
>> (I'm aware of a cloud PVR that streams the original MPEG-2 data
>> captured from DVB-T, but they also offer H.264 recompressions. So if
>> they chose to migrate from using out-of-browser viewer apps to HTML5,
>> they could. But that service is irrelevant to EME, since they don't
>> add any DRM to the data captured from DRMless DVB-T broadcasts.)
>>
>
> Correct. DVB-T is not subjected to encryption as far as I understand. Of
> course that is not the case for DVB-S.
>
>
>> > A better question would be whether and when they intend to use something
>> > other than MPEG-2?
>> ...
>> > There is something called legacy systems.
>>
>> Do you expect the services you are talking about to target Chrome or
>> IE using HTML5/EME? Or just Samsung/LG/Sony TVs?
>>
>
> I can't answer for all content service providers, but from what I know,
> most providers desire that they can transmit content to any device, any
> where, any time. So it all comes down to what the device supports and what
> (un-transcoded) resource is available. In certain contexts, transcoding
> resources can ameliorate differences between device supported and service
> provided A/V formats. But at the bottom of the line, service providers
> still consider MPEG-2 to be the default, certainly to traditional devices
> (like TVs and DVDs, etc). That some modern UAs don't support MPEG-2
> decoding is considered a negative that has to be worked around.
>
> Please do not construe the above to mean that I or the W3C member I
> represent prefer MPEG-2 over H.264 (or any other specific format). That
> simply isn't the case. The issues are: what are the legacy media formats
> and deliver systems, what is supported by the device (natively), and what
> transcoding resources are available (if any) if the source and destination
> don't match.
>