OK, thanks for the clarification. As the API is experimental, I think we should either prefix it or move it to another namespace.
Anssi, what is your input on this? Kenneth On Mon, Nov 18, 2013 at 4:48 PM, Huo, Halton <halton....@intel.com> wrote: > The namespace is not exposed to *sysapp.*, it is navigator.. As I said, > we synced this namespace before with Anssi. Anyway, we could change that as > you suggest. But I would like you and Anssi make a decision. > > > > Thanks, > > Halton. > > *From:* Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com] > > *Sent:* Monday, November 18, 2013 7:35 PM > *To:* Jiang, Xiaodan > *Cc:* Huo, Halton; crosswalk-dev@lists.crosswalk-project.org > > *Subject:* Re: [Crosswalk-dev] Intent to Implement: [Android] W3C > DeviceCapabilities/Codecs > > > > OK, sounds good! > > > > I would still not use the sysapps. name space though, maybe > sysapps.experimental or similar. > > > > On Mon, Nov 18, 2013 at 12:33 PM, Jiang, Xiaodan <xiaodan.ji...@intel.com> > wrote: > > 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> > 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 ﹆﹆﹆ > > > > > > -- > 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
