HTML5 on consoles

[jeff_rigby]

What do you make of this direction for Chrome/Chromium/ChromeOS?

http://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html

http://www.engadget.com/2011/01/11/google-will-drop-h-264-support-from-chrome-herd-the-masses-towa/

That's an interesting direction. Unfortunately, I encode all my videos in H264...

To that end, we are changing Chrome’s HTML5 <video> support to make it consistent with the codecs already supported by the open Chromium project. Specifically, we are supporting the WebM (VP8) and Theora video codecs, and will consider adding support for other high-quality open codecs in the future. Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the (H.264 codec) will be removed and our resources directed towards completely open codec technologies.

So the HTML5 <video> tag will NOT be H.264. Web sites using the Embedded HTML5 <video> tag will not be supported by Chrome unless they use VP8 or Thedora.

That explains my previous posts where support for embedded video was removed from Sony 2011 products with the Opera browser. The CE products have hardware support for the H.264 codec but may not have hardware support for other codecs. The Broadcom chip may not be be fast enough to CPU decode the video and audio VP8 or Thedora streams. Or the reporter got it wrong and Opera browsers already support VP8 for embedded video so they won't work with current embedded video.

VP8 is supposed to require fewer resources to decode and play but the CPU is not as efficient as built in hardware codecs support so this may hit handhelds hard as far as battery life.

As I see it, this is only going to affect newer browsers and hardware platforms with newer browsers. Who are they; Android and Apple iOS (iPad, iPod, iTouch). For Android with Chrome browsers, a browser update, for Apple....the same but will Apple follow the Google Lead or will this create another schism in Webkit Open Source code.

 

[Gubbi]

I thought the whole point of implementing a video-tag was to expose the codecs that the platform supports.

That is, why do Google get a say in what codecs Chrome supports ? Chrome should query the OS and play back video in any codec that the platform supports.

Or is this about native, builtin support ? In that case I understand they don't want to pay for it.

Cheers

 

[jeff_rigby]

http://www.engadget.com/2011/01/12/samsung-wifi-enabled-rf4289-fridge-cools-eats-and-tweets-we-go/

Samsung Refrigerator, the first of its kind to feature integrated WiFi (HTML5). To be fair the unit provides a few pragmatic features too like the ability to view Google calendars, check the weather, download recipes from Epicurious, or leave digital notes

 

[jeff_rigby]

I thought the whole point of implementing a video-tag was to expose the codecs that the platform supports.

That is, why do Google get a say in what codecs Chrome supports ? Chrome should query the OS and play back video in any codec that the platform supports.

Or is this about native, builtin support ? In that case I understand they don't want to pay for it.

Cheers

They have apparently left the door open to support other High quality codecs in the future but for now only WebM (VP8) or Vorbis.

Speculation on the web is that Google and Flash are attempting to rein in Apple. Apple is pushing an all HTML5 web (no Flash) with <video> tag being H.264 and Quicktime.

DRM is missing from HTML5 <video> tag so it is only being used for non-copyrighted material on other platforms. Google just purchased Widevine so I expect a DRM scheme for HTML5 <video> tag to be made open source soon. That will be the other shoe dropping. VP8 with hooks for DRM and DRM Tool open source.

 

[jeff_rigby]

In the following picture below, the bottom most layer in blue is Sony provided device drivers for their products. The next layer up in Red are Open source libraries that can be used by developers and Sony provides a link to those libraries and will include applicable libraries in their products to support the framework. The top purple layer are third party developed applications.

What we can glean from this are the libraries that have been or are to be ported to the PS3. Many of these are necessary for a HTML5 Webkit port to the PS3. For instance Windows Manager is one I recognize as not in the PS3 now. Media player service is probably the Sony provided cell optimized H.264 codec player with hooks for adaptive streaming and DRM already in the PS3. SQLite was probably already ported as HTML5 requires it and the IPTV applications may be using it.

Or Sony can go the Android OS route. In the above picture Webkit should be a part of the Red area as it provides a library of callable routines just as it does for Android below. The Browser is an application in both Android below and the Sony SNAP picture.

The difference is in a digital ecosystem Sony will have platforms and home automation products that talk to each other and share information. That is considered low level and libraries used to do this are in the RED areas of the SNAP developers picture but are missing from Android.

In the above picture the blue areas are Android running on the mustard color Dalvik engine. Libraries in both pictures above are compiled "C".

The Android model has thousands of Apps but performance will not be equal to the Sony SNAP native app model.

The Snap model has no apps but has superior flexibility and performance. There is the possibility that Apple APP developers could port apps to the PS3 and PS3 developers could port apps to the iOS platforms.

IF we think of Android as a super UI and provide more low level native language support; it might work. My guess is Sony is too far behind Apple and can't catch up using the native application model. This might be why the Snap program was put on hold.

 

[makattack]

I can't quite figure out your purpose of printing the architecture diagrams that detail the layers of the Android and SNAP development/operating environments.

Obviously, there are many architectural diagrams that share the look of the above.

Just look at the XNA/.NETCF diags a MS blogger created:

http://blogs.msdn.com/b/abhinaba/archive/2010/03/18/what-is-netcf.aspx

It's a traditional multi-tier layering of modules, somewhat akin to the OSI network layer model, but for software instead of networking hardware/software.

That the android, SNAP, and for that matter, Win7Phone frameworks share a lot of stuff in common... is to be expected.

 

[jeff_rigby]

I can't quite figure out your purpose of printing the architecture diagrams that detail the layers of the Android and SNAP development/operating environments.

Obviously, there are many architectural diagrams that share the look of the above.

Just look at the XNA/.NETCF diags a MS blogger created:

http://blogs.msdn.com/b/abhinaba/archive/2010/03/18/what-is-netcf.aspx

It's a traditional multi-tier layering of modules, somewhat akin to the OSI network layer model, but for software instead of networking hardware/software.

That the android, SNAP, and for that matter, Win7Phone frameworks share a lot of stuff in common... is to be expected.

It's not that it's a multi-layer diagram but the libraries of open source software in both Android and the Sony SNAP program. When you research the PD library names and their function you can get an idea of what Sony plans for the Digital Ecosystem, what still has to be ported to the PS3 etc.

Your opinion that they "share a lot of stuff in common with Win7Phone" is informative. Will features seen in Win7 be in the PS3 if the libraries serve similar functions. The diagram you cite above is for the processes Silverlight uses and would be more relevant to Flash or Air not native language apps. It does tell us that MS is serious about games using Silverlight on the Xbox360. Perhaps Sony will do something similar with Flash on the PS3.

As a game console some of the PD libraries weren't needed and were not in the PS3. Webkit requires support from several of the libraries listed. We will be getting windows support, how will that be used?

Also many of the question about third party applications for the PS3 were answered in part by the diagram. App manager, Registry service and Store Client tell us that applications are going to be native language, digitally signed and for sale in a PSN store.

That does not mean that we won't have Javascript, Java, Android or Flash applications just as we have PS3 OS native games, Minis (PSP engine games) and in the future possibly other platform's games.

Shifty was correct in that Sony planned for native language third party applications on all platforms and CE products including the PS3. I believe we will be getting simple javascript applications, some possibly free. Less likely but still possible are digitally signed Flash applications for sale in the PSN store. The SNAP program would also support Linux, Windows and possibly other platforms. They could expand and have app stores for other platforms.

That the Snap developer website appeared and was almost immediately put on hold also has major implications.

 

[patsu]

What do you make of this direction for Chrome/Chromium/ChromeOS?

http://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html

http://www.engadget.com/2011/01/11/google-will-drop-h-264-support-from-chrome-herd-the-masses-towa/

That's an interesting direction. Unfortunately, I encode all my videos in H264...

The video tag standard supports alternate codecs. So it's a business move. H.264 momentum will probably be unaffected by this change (It's too well established). As you can tell from the NetFlix approach, the content provider can switch from a <video> tag to an <object> tag on-the-fly easily.

H.264 sources can be downloaded from somewhere else. The device companies can include a H.264 plugin by default anyway (or included in the Google App).

 

[scooby_dooby]

H.264 momentum will probably be unaffected by this change (It's too well established)

Totally disagreed. Momentum in this case is not determined by device manufacturer's, but rather the publishers of online video. And in that sense, H264's momentum in the browser has come to a screeching halt, in one move Google has essentially cemented Flash as the only good cross platform way to deliver video going forward.

h264 was on it's way to the defacto standard, only Firefox and Opera were the holdouts, with Firefox implying that they would also support H264 if they had to, which would've left only Opera with it's teeny marketshare.

Now, it's fairly evenly split (among browsers which are HTML5 compliant), which basically stops H264 in it's tracks, and gives Mozilla the backing to stick to their original guns. Now either MS and Apple both add support for WebM (unlikely), or HTML5 video becomes a major paint to support, especially for bloggers or other smaller production teams that don't have the infrastructure to batch output multiple copies of every video.

You're right that H264 is not going anywhere, it's far too widespread with hardware acceleration everywhere, but going forward, the only good vehicle to deliver that in the browser is Flash, not <video />

 

[patsu]

If Flash can deliver video via a plugin, there is no reason why H.264 can't deliver the same consistency for all browsers. There will be H.264 plugins and/or video tags on every browser. Plus possibly a different Chromium build (with H.264 video tag support) distributed via Google App Store.

The availability of premium H.264 content will help push the standard. The pervasiveness of H.264 on assorted devices will help push it too. Learning from iTunes, the content providers are unlikely to put all their eggs in a single vendor's basket. If MPEG LA keep their words, H.264 is also royalty-free for free content.

WebM is great for free content though.

 

[jeff_rigby]

If Flash can deliver video via a plugin, there is no reason why H.264 can't deliver the same consistency for all browsers. There will be H.264 plugins and/or video tags on every browser. Plus possibly a different Chromium build (with H.264 video tag support) distributed via Google App Store.

The available of premium H.264 will help push it. The pervasiveness of H.264 on assorted devices will help push it too. Learning from iTunes, the content providers are unlikely to put all their eggs into a single vendor's basket. If MPEG LA keep their words, H.264 is also royalty-free for free content.

WebM is great for free content though.

http://dev.opera.com/articles/view/opera-supports-webm-video/

The WebM format consists of VP8 video and Vorbis audio wrapped inside a .webm container. This format is based on the Matroska media container format. WebM offers high-quality video with fast seeking.

http://www.matroska.org/

Welcome to the Home of Matroska the extensible, open source, open standard Multimedia container. Matroska is usually found as .MKV files (matroska video), .MKA files (matroska audio) and .MKS files (subtitles) and .MK3D files (stereoscopic/3D video). It is also the basis for .webm (WebM) files.

the list of chip makers supporting the WebM project was long, and included every major chip maker except Intel. This support is now starting to bear fruit: several chipmakers have announced chips with VP8 decoding built-in. For occasion, Freescale announced its i.MX6 line of processors last week, which includes several multicore ARM chips with VP8 support built-in. Google states that 20 chip makers have licensed the VP8 hardware decoder already.

WebM supporters: http://www.webmproject.org/about/supporters/

http://blog.webmproject.org/2011/01/availability-of-webm-vp8-video-hardware.html

The WebM/VP8 hardware decoder implementation has already been licensed to over twenty partners and is proven in silicon. We expect the first commercial chips to integrate our VP8 decoder IP to be available in the first quarter of 2011. For example, Chinese semiconductor maker Rockchip last week demonstrated full WebM hardware playback on their new RK29xx series processor at CES in Las Vegas (video below).

Android 2.3 VP8 tablets and TVs

 

[patsu]

Yes, but millions of existing devices can't play WebM. The device makers also won't stop supporting H.264.

WebM's real power lies in being free, so our children and us can also enjoy free videos without any corporate strings attached.

It is however unlikely to touch H.264. A proper business model and end-to-end ecosystem have been established. Google didn't exactly make friends with the premium content providers with GoogleTV too. They should have focused on that front first. In any case, competition is good. They made H.264 free for free content. So I'm not complaining !

Since I lost my 3GS, I was going to buy an Android phone to try out. *If* the new Android phone can't play H.264 properly, I probably will remain on iOS.

 

[jeff_rigby]

Yes, but millions of existing devices can't play WebM. The device makers also won't stop supporting H.264.

WebM's real power lies in being free, so our children and us can also enjoy free videos without any corporate strings attached.

It is however unlikely to touch H.264. A proper business model and end-to-end ecosystem have been established. Google didn't exactly make friends with the premium content providers with GoogleTV too. They should have focused on that front first. In any case, competition is good. They made H.264 free for free content. So I'm not complaining !

Since I lost my 3GS, I was going to buy an Android phone to try out. *If* the new Android phone can't play H.264 properly, I probably will remain on iOS.

Only HTML5 <video> tag is affected and that is only in browsers. All applications, Netflix, VUDO, Hulu etc. are not affected. HTML5 <video> tag has always been something other than H.264 for all browsers except IE, Apple and Chrome versions before 10.0. Now with Google's announcement, going forward only Apple and IE support H.264 for HTML5 <video> tag.

Apple and IE can support VP8 with a plugin. Flash will support H.264 in Android phones.

By the way H.264 is not free: "Opera for example has stated that they can't afford the $6,5 million year/fees required by H.264. Yes for relatively small companies this may be a big deal. I'm sure there are other cases, and also we can't ignore new, non-established players or developers in poor countries that would be out of the game because of the potential fees."

 

[patsu]

By the way H.264 is not free: "Opera for example has stated that they can't afford the $6,5 million year/fees required by H.264. Yes for relatively small companies this may be a big deal. I'm sure there are other cases, and also we can't ignore new, non-established players or developers in poor countries that would be out of the game because of the potential fees."

This is the real problem hindering universal H.264 adoption, with or without WebM.

 

[jeff_rigby]

This is the real problem hindering universal H.264 adoption, with or without WebM.

Just so you don't think H.264 is being dropped, the video in the last link a couple of posts ago featured the first VP8 hardware support in a 10 inch tablet and the specs follow:

RK2918 now supports Gingerbread (Android2.3) for mobile Internet devices (MIDs), smartphones and Internet TVs, etc. Highlights of the RK29XX include:

- 1.2G ARM Cortex A8 core with Neon and 512KB L2 cache
- High performance 2D and 3D processors support OPENGL ES 2.0 and OPEN VG, Support 60M tri/s max
- 1080p video decoding for H.264, VP8, RV, WMV, AVS, H.263, MPEG4, etc.
- 1080p video encoding for H.264
- Support DDRIII, DDRII, mobile DDR memory
- 24bit HW ECC for MLC NAND, support e-MMC boot
- Three USB ports for device, host, 3G module
- Two SD ports for SD card and WiFi
- Sensors interface for front and rear camera, up to 5M
- Standard TFT/EPD controller for variable panels
- MAX 8 channel I2S and SPDIF output for HD movie
- TS port for mobile and terrestrial TV, ATSC-T/MH, etc
- Ethernet networking interfaces
- Support VoIP
- Support Android 2.3 and future version

Made in China and Shipping in March. TVs, Tablets and Smartphones

 

[patsu]

Should be fine. For premium content, the "bottleneck" is the DRM, not the video codecs. From consumers' perspective, it's good to have a free alternative to keep MPEG LA in check. The same chip can decode and encode H.264.

 

[jeff_rigby]

Should be fine. For premium content, the "bottleneck" is the DRM, not the video codecs. From consumers' perspective, it's good to have a free alternative to keep MPEG LA in check. The same chip can decode and encode H.264.

Not mentioned is that the Rock chipset was demoed at CES 2011 in 10 inch tablets and TVs with Android 2.3 made in China and shipping sometime in March.

I expect this to drive both price and features in CE equipment for the latter part of 2011 and on.

 

[scooby_dooby]

If Flash can deliver video via a plugin, there is no reason why H.264 can't deliver the same consistency for all browsers. There will be H.264 plugins and/or video tags on every browser. Plus possibly a different Chromium build (with H.264 video tag support) distributed via Google App Store.

Meh. If you're targeting everyone you can't rely on plugins, a large percentage of people simple can't install them due to security issues, or won't due to security concerns. Flash has a 98% install base already, which makes it unique among plugins.

I really can't see H264 (+plugin) gaining any kind of momentum now inside of the browser, it's just DOA.

 

[jeff_rigby]

Meh. If you're targeting everyone you can't rely on plugins, a large percentage of people simple can't install them due to security issues, or won't due to security concerns. Flash has a 98% install base already, which makes it unique among plugins.

I really can't see H264 (+plugin) gaining any kind of momentum now inside of the browser, it's just DOA.

Agree, Opera, Firefox and Chrome being cross platform (at least from what I have read) do not support plugins for the browser, IE and Apple browsers do as they are platform dependent and have plugins for just about all codecs. To be clear, IE for instance can write codecs for a x86 knowing it's only running on a X86 but Chrome or Opera would have to have custom codecs for each hardware platform which is too much work so they limit the support.

So IE and Apple can support WebM with a plugin but Chrome and other cross platform browsers can't afford to support multiple codecs on multiple hardware platforms. So WebM or VP8 will likely become the default standard for HTML5<video> tag

http://www.techspot.com/news/41995-google-to-release-webm-plugins-for-ie9-and-safari.html

Google to release WebM plugins for IE9 and Safari

Posted 3 days ago by Emil Protalinski | Filed in Software
After Google announced that it would be dropping support for H.264 in Chrome and only support WebM going forward, the search giant has revealed that it will offer WebM plugins for Microsoft's Internet Explorer 9 and Apple's Safari. It appears…

 

[makattack]

Since I lost my 3GS, I was going to buy an Android phone to try out. *If* the new Android phone can't play H.264 properly, I probably will remain on iOS.

My android 2.2 based TMobile/HTC G2 plays all my h264 encoded videos perfectly well...