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

Re: how does EME/DRM effect captioning

From: Glenn Adams <glenn@skynav.com>
Date: Wed, 3 Apr 2013 05:19:44 -0600
Message-ID: <CACQ=j+eotGRnH=3i68LXaC-nLPbTLFBbeb4e9fpBYUKTuEJrYQ@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: Steve Faulkner <faulkner.steve@gmail.com>, HTMLWG WG <public-html-media@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
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.
Received on Wednesday, 3 April 2013 11:20:36 UTC

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