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> 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] *On Behalf Of *Kenneth > Rohde Christiansen > *Sent:* Monday, November 18, 2013 5:13 PM > *To:* Fei, Yiran > *Cc:* 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> 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 > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev > > > > > > -- > Kenneth Rohde Christiansen > Web Platform Architect, Intel Corporation. > Phone +45 4294 9458 ﹆﹆﹆ > -- 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
