[opendtv] Re: News: New Cable Fight at Hand > Adaptive Streaming convergence
- From: Kilroy Hughes <Kilroy.Hughes@xxxxxxxxxxxxx>
- To: "opendtv@xxxxxxxxxxxxx" <opendtv@xxxxxxxxxxxxx>
- Date: Tue, 5 Apr 2011 18:24:22 +0000
I can only guess, but Adobe is the dominant presentation and authoring platform
on the Web today, so it doesn't exactly float their boat if everyone switches
to a cross platform standard for adaptive streaming like DASH, or cross
platform content protection like MPEG Common Encryption ('cenc' scheme), or
interactive presentation formats like the various App Stores for different
platforms or HTML5 with TBD support for protected adaptive streaming. They
have contributed a lot to DECE UltraViolet video format, which most companies
see as a basic Interop enabler, like HTTP protocol, which floats all boats
(Apple being the exception with a closed system with its own critical mass).
Google has a big enough ecosystem, they just implement whatever they want and
then tell W3C and IETF to make it a standard later (with mixed results). I
haven't seen them in the old school ISO standards orgs that collaboratively
generate or standardize new technology (or patents, depending on your
perspective).
After the GoogleTV launch failure and wakeup call that they can't use TV shows
and movies for free to sell advertising (like they are doing with web pages,
photos, books, music, picture of your house, email, etc.), they dropped over a
hundred million the next week on one of the DRM and adaptive streaming
companies in DECE (Widevine) and hit the circuit with Netflix to lock up
content rights. So, we'll see if they develop the Widevine platform into a
Google product they want blessed as a "standard" like WebM, or if they'll join
in on DASH, Common Encryption, UltraViolet, TV Everywhere, etc. industry
standards.
Meanwhile, in W3C the browser makers led by Google have been restricting HTML5
functionality to what is built into each browser, creating the myth that the
video tag depends on a royalty free video decoder being built into every HTML 5
browser. That theory gets even less viable as it extends to adaptive streaming
and DRM running in browser code.
Now a Web on TV group in W3C, Internet TV, cell phone, and other device
manufacturers, have introduced the reality that decoding of video, multichannel
audio, subtitles, DRM and key management, adaptive streaming network and buffer
management, accelerated video composition, etc. are best accomplished by a
device-specific media handler that can be registered in any HTML5 browser and
lets each device implement the video pipeline in its own hardware/software, and
not be limited to what the browser can do running its code in the CPU. In
fact, a standard media format, encryption, and streaming protocol can be used
by a device-specific app (like EPG) or Android, IOS, etc. platform app as equal
(but less portable) alternatives to HTML5 video tag web apps.
Standardization of the basic audio/video/subtitle/DRM and streaming protocol
adds more value/control to devices that actually implement the video pipeline,
and less value/control to browser/OSs that want to "own" those boxes in
exchange for a small slice of ad revenue.
Kilroy Hughes
-----Original Message-----
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
Behalf Of mike@xxxxxxxxxxxxxx
Sent: Tuesday, April 05, 2011 4:54 AM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: News: New Cable Fight at Hand > Adaptive Streaming
convergence
Kilroy,
Why Google and Adobe have not cooperated with MPEG DASH?
Mike Tsinberg
http://keydigital.com
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Kilroy Hughes <Kilroy.Hughes@xxxxxxxxxxxxx>
Sender: opendtv-bounce@xxxxxxxxxxxxx
Date: Tue, 5 Apr 2011 06:15:20
To: opendtv@xxxxxxxxxxxxx<opendtv@xxxxxxxxxxxxx>
Reply-To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: News: New Cable Fight at Hand > Adaptive Streaming
convergence
Kon,
I think MPEG DASH (Dynamic Adaptive Streaming over HTTP) will be adopted as a
common adaptive streaming "protocol" (actually an XML manifest and related
"application protocol", nothing to do with changing HTTP 1.1. network
protocol). The major cell phone, TV, cable, computer, etc. companies
(including Apple, Netflix, and Microsoft ... basically, everyone but Google and
Adobe) cooperated to write it. We could have used more CDN participation, so
check out the DIS (Draft International Standard) if you get a chance.
However, that doesn't solve the problem of dozens of different transport
container/stream formats, file layouts, elementary stream formats, codecs,
encryption/DRM systems, etc.; each of which can result in playback failure if
one bit is in the wrong place.
MPEG's Common Encryption scheme (also DIS stage) can help by allowing one
encrypted file to be used by multiple DRMs (analogous to DVB simulcrypt for
broadcast).
Converging on a common media format is harder (meaning a spec like ATSC, DVD,
BD, not one product like iPhone or Flash).
UtraViolet is the best shot at a common media format for Internet that I'm
aware of. It specifies the whole media stack at the same level of detail as
the publishing formats listed above. A million consumers can use the same copy
of "Batman X" or whatever for download or adaptive streaming or their "cloud
locker", greatly improving CDN efficiency vs. a million separate copies.
Most internet content was migrating to AVC and MPEG-4 ISO file format (with
different Profiles, Levels, and some "special" versions, but trending well),
but a common container format now remains split because MPEG-2 TS was brought
back from retirement on the Internet by the popularity of iThingies and the HLS
format using M2TS (after Apple invented MPEG-4 ISO File Format and used it in
QuickTime forever ... how ironic).
Google isn't helping anybody but Google by introducing another incompatible
container and codec format for YouTube, Chrome, GoogleTV, Android ... the world
according to Google.
It could have a good effect if AVC Baseline decoders become royalty free in
response, and Google declares victory, shipping browsers with free AVC Baseline
decoders. Then TVs, cell phones, BD players, etc. can continue to use their
high performance AVC chips instead of browser code burning up small CPUs. User
generated content can use Baseline and commercial systems that can't afford the
lower efficiency of VP8 and Baseline can use the bandwidth efficiency and
higher video quality of AVC High Profile. A billion video devices out there
already have paid for AVC decoder hardware that an HTML 5 browser could use,
and AVC internet content doesn't have royalties. Google isn't going to replace
overnight billions of AVC videos and devices in the market and all video
devices shipping for the foreseeable future that will include AVC decoders.
So, if WebM succeeds at all it will result in double the implementation and
testing burden and double the trouble for consumers, not a sing le
interoperable format.
I understand the business model of turning other people's devices into power
supplies for a Chrome advertising browser/OS that shows other people's content,
but tapping into existing hardware decoders doesn't stop that as long as W3C
gets the device and video tag APIs done in our lifetime, or the browser
supports native OS APIs, like all the major Windows and Apple browsers do now
for video acceleration. Maybe getting others to write decoder drivers in a
"free" OS for each hardware platform has problems I don't appreciate.
Kilroy Hughes
-----Original Message-----
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
Behalf Of Kon Wilms
Sent: Friday, April 01, 2011 3:16 PM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: News: New Cable Fight at Hand
On Fri, Apr 1, 2011 at 2:50 PM, Manfredi, Albert E
<albert.e.manfredi@xxxxxxxxxx> wrote:
> The multiple unnecessary standards become a nuisance for consumers. Maybe not
> a huge nuisance, but they still can't help but increase the price of
> everything. For example, they create a need for CDNs to unravel the mess. And
> they make it virtually impossible for video cards to work equally well on all
> streams. If that should ever happen, someone will quickly create a new
> standard. It's a racket, that's all.
Totally agree. It's been a few years for me concentrating solely on 'internet'
and 'mobile' streaming now, and in that time there has been considerable churn.
The good thing about being a CDN is you have to embrace all technologies since
any one may become the 'popular' one.
The bad things is making them all interoperate. But the way I see it going is
HTTP dynamic/segmented streaming served like a commodity to HTML5-based
decoders. Everything else will just be fluff. The codec battle will be between
H264 and WebM. I see WebM winning -- it's not even out of the gates and the
next rev of Android hardware coming in the next few months will have hardware
acceleration (and the CDN streaming software is already tooling up to support
it).
Cheers
Kon
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
¢çCRP‚D€D~º&¶Ž¥éÃMYb²Ø§·
0k+²)ඔ5%H$HG(šf§v)ò¢êî±êÜ¢wâ‚êÚ¶*'±ëmŠx,jÑkyââ²Û(®
Other related posts:
