Kenneth, The plan, to implement device capability API and also add the codec API group, has been discussed in length between Sakari, Anssi, Hongbo and Halton. It is well understood that there are various opinions regarding the device capability API, but the decision was made to pick the reasonable API groups and implement them in Crosswalk, which will in return provide valuable feedback to the spec evolution and push the spec moving forward.
Regards, --Xiaodan From: Crosswalk-dev [mailto:crosswalk-dev-boun...@lists.crosswalk-project.org] On Behalf Of Kenneth Rohde Christiansen Sent: Monday, November 18, 2013 5:38 PM To: Huo, Halton Cc: crosswalk-dev@lists.crosswalk-project.org Subject: Re: [Crosswalk-dev] Intent to Implement: [Android] W3C DeviceCapabilities/Codecs Whether it is listed on the website as a Phase 2 item or not, doesn't mean that it will be added ever. This priority list was made when the working group started without people deciding whether it actually makes sense to have such an API or not, or whether it should be one spec or multiple. In Toronto the general consensus was that this is not useful as such (no compelling use-cases and it is an API consisting of multiple not really related things) and that it would be better be split the useful parts of the proposal into multiple smaller specs which could be reevaluated in case that valid use-cases were found. Why not split out the codec parts into a Device Capabilities: Codecs spec or similar? I guess this might be one of the most useful parts for hosted apps. Kenneth On Mon, Nov 18, 2013 at 10:30 AM, Huo, Halton <halton....@intel.com<mailto:halton....@intel.com>> wrote: Hi Kenneth, The DeviceCapabilities decide to implement by ignoring it is a Phase2 spec. And the namespace is confirmed with Anssi already. CC Sakari and Anssi for confirm. Thanks, Halton. From: Crosswalk-dev [mailto:crosswalk-dev-boun...@lists.crosswalk-project.org<mailto:crosswalk-dev-boun...@lists.crosswalk-project.org>] On Behalf Of Kenneth Rohde Christiansen Sent: Monday, November 18, 2013 5:13 PM To: Fei, Yiran Cc: crosswalk-dev@lists.crosswalk-project.org<mailto:crosswalk-dev@lists.crosswalk-project.org> Subject: Re: [Crosswalk-dev] Intent to Implement: [Android] W3C DeviceCapabilities/Codecs As far as I remember the W3C SysApps Working Group decided to not take on Device Capabilities, thus stating this to be a W3C spec/API is wrong. Actually there was objections to such an API and lacking use-cases was also stated as a reason. Anssi should be able to provide more feedback on this. Until any working group decided to proceed with this, this is just an Intel proposal (which was so far rejected). This said, I am not sure it makes sense to have this under the "sysapps." namespace. Kenneth On Fri, Nov 15, 2013 at 6:53 AM, Fei, Yiran <yiran....@intel.com<mailto:yiran....@intel.com>> wrote: Description This feature is part of the Device Capabilities APIs defined in W3C document. It provides web runtime applications with the ability to get the supported audio/video codecs’ information(*) on the client machine(Android device). Take an example as the user case, with this information, the server can provide the most appropriate encoding format of audio/video stream if possible. (*) The required information: Audio Video format (DOMString) YES YES hwAccel (Boolean) N/A YES encode (Boolean) N/A YES Spec http://w3c.org/2012/sysapps/device-capabilities/ Affected component java API: runtime/android/java/src/org/xwalk/runtime/extension/api/device_capabilities js API: sysapps/device_capabilities test case: test/android/data Related feature in Jira https://crosswalk-project.org/jira/browse/XWALK-48/ Target Release Crosswalk-M3 Target Platform Android Implementation details 1) On Android version >= 4.1(API level >= 16): The implementation uses the 'MediaCodec' APIs which is available since Android 4.1(API level 16) to get the codec list. Through this API, we can get the codec list stored in ROOTDIR_OF_ANDROID/system/etc/media_codec.xml to satisfy the requirements in spec. 2) On Android 4.0(API level 15): Android 4.0 does not offer 'MediaCodec' API, as well as file ROOTDIR_OF_ANDROID/system/etc/media_codec.xml file in its system. So we need offer a fallback solution for 4.0. The solution is offer an 'MediaCodec' compatible API, this API will return the hard coded codec lists. The original list comes from media_codec.xml on 4.1. 3) Parse the name string In Android 4.x, all codecs are based on the OpenMAX IL framework, and the format name we get from the system are always wrapped in many other strings, such as ‘OMX.google.h263.decoder’. As a result, we need to parse it out. Our method is maintaining a constant list of the codec names(According to: http://www.chromium.org/audio-video and https://developer.mozilla.org/en-US/docs/HTML/Supported_media_formats) and parse each name(such as h263) out according to the list. 3) Current problem: Besides the hardcode on 4.0, we cannot get the hardware acceleration status either. By either using current Android API(up to 4.2) or parsing files, there's no way to figure out whether a codec is hardware-accelerated based on current Android system, so this value is set to ‘false’ by default now. Regards, Yiran & Yuanhang _______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org<mailto:Crosswalk-dev@lists.crosswalk-project.org> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev -- Kenneth Rohde Christiansen Web Platform Architect, Intel Corporation. Phone +45 4294 9458<tel:%2B45%204294%209458> ﹆﹆﹆ -- Kenneth Rohde Christiansen Web Platform Architect, Intel Corporation. Phone +45 4294 9458 ﹆﹆﹆
_______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
