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ââ²Û(®