- From: Glenn Adams <glenn@skynav.com>
- Date: Wed, 3 Apr 2013 05:19:44 -0600
- 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>
- Message-ID: <CACQ=j+eotGRnH=3i68LXaC-nLPbTLFBbeb4e9fpBYUKTuEJrYQ@mail.gmail.com>
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