Talk:Android hardware: Difference between revisions

From Official Kodi Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 4: Line 4:
* http://youtube-eng.blogspot.de/2015/04/vp9-faster-better-buffer-free-youtube.html VP9 needed for "''faster, better, buffer-free YouTube videos''", and "''Thanks to our device partners, VP9 decoding support is available today in the Chrome web browser, in Android devices like the Samsung Galaxy S6, and in TVs and game consoles from Sony, LG, Sharp, and more. More than 20 device partners across the industry are launching products in 2015 and beyond using VP9.''"  
* http://youtube-eng.blogspot.de/2015/04/vp9-faster-better-buffer-free-youtube.html VP9 needed for "''faster, better, buffer-free YouTube videos''", and "''Thanks to our device partners, VP9 decoding support is available today in the Chrome web browser, in Android devices like the Samsung Galaxy S6, and in TVs and game consoles from Sony, LG, Sharp, and more. More than 20 device partners across the industry are launching products in 2015 and beyond using VP9.''"  
* http://en.wikipedia.org/wiki/VP9 ''Chromium, Chrome, Firefox, and Opera support playing VP9 video format in the HTML5 video tag.''
* http://en.wikipedia.org/wiki/VP9 ''Chromium, Chrome, Firefox, and Opera support playing VP9 video format in the HTML5 video tag.''
==MPEG-2 CPU decode is not HW decode==
Should the matrix really be green for those hardware claiming "''MPEG-2 (CPU)''"? There is no way that we can verify performance of proper MPEG-2 software decode, especially with software decode with deinterlacing, so why not just put a "No" on devices which can only do MPEG-2 software decode? Hardware decode is hardware decode, and if a device can not perform hardware decode of a codec then that should not be green in my opinion. Most modern Android hardware today could now even software decode H.264 in 1080p but again that is noting that we can verify so we could not either list "''H.264 (CPU)''" or should we?


== unnecessary detail ==
== unnecessary detail ==

Revision as of 14:40, 4 May 2015

VP9 required for YouTube in 4K

VP9 hardware decoding support needed for YouTube support in 4K (2160p), plus even YouTube in 720p and 1080p benefits as it uses half the bandwidth on H.264 so wondering if that is not enough reason to have VP9 i this matrix for Android hardware?

  • http://youtube-eng.blogspot.de/2015/04/vp9-faster-better-buffer-free-youtube.html VP9 needed for "faster, better, buffer-free YouTube videos", and "Thanks to our device partners, VP9 decoding support is available today in the Chrome web browser, in Android devices like the Samsung Galaxy S6, and in TVs and game consoles from Sony, LG, Sharp, and more. More than 20 device partners across the industry are launching products in 2015 and beyond using VP9."
  • http://en.wikipedia.org/wiki/VP9 Chromium, Chrome, Firefox, and Opera support playing VP9 video format in the HTML5 video tag.

MPEG-2 CPU decode is not HW decode

Should the matrix really be green for those hardware claiming "MPEG-2 (CPU)"? There is no way that we can verify performance of proper MPEG-2 software decode, especially with software decode with deinterlacing, so why not just put a "No" on devices which can only do MPEG-2 software decode? Hardware decode is hardware decode, and if a device can not perform hardware decode of a codec then that should not be green in my opinion. Most modern Android hardware today could now even software decode H.264 in 1080p but again that is noting that we can verify so we could not either list "H.264 (CPU)" or should we?

unnecessary detail

I really appreciate any work that is done on the wiki, and I don't want to do anything to discourage people, but please resist the urge to add unnecessary detail on a page such as this. Normally details are good, but on this page the entire point is to help clear up a very confusing aspect of XBMC hardware support.

The three decoding categories are grouped basically by what you are likely to see as supported or not. There's no point in listing two codecs in their own columns if they are always supported in mediacodec/libstagefright/amlcodec. "H.264" is mentioned simply as the most common example of the common codecs. If a codec isn't currently supported by any chipset/decoding codec in XBMC then there's also no point in making a column for that, and it should instead be noted "globally". -- Ned Scott (talk) 00:47, 25 February 2014 (EST)