Hi,

I would not like to prefix it. Actually, I think it would be fine to use the 
namespace as in the the spec (navigator). All the SysApps APIs are now more or 
less experimental and if we start second guessing what is more mature than the 
other, we’ll have this discussion for each API.

Thus, my recommendation is just to implement the spec as it is now.

BR; Sakari

From: Kenneth Rohde Christiansen 
<kenneth.christian...@gmail.com<mailto:kenneth.christian...@gmail.com>>
Date: Monday, November 18, 2013 at 18:04
To: "Huo, Halton" <halton....@intel.com<mailto:halton....@intel.com>>
Cc: 
"crosswalk-dev@lists.crosswalk-project.org<mailto:crosswalk-dev@lists.crosswalk-project.org>"
 
<crosswalk-dev@lists.crosswalk-project.org<mailto:crosswalk-dev@lists.crosswalk-project.org>>
Subject: Re: [Crosswalk-dev] Intent to Implement: [Android] W3C 
DeviceCapabilities/Codecs

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<mailto: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<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<mailto: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<mailto: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<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<mailto: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<tel:%2B45%204294%209458> ﹆﹆﹆



--
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

Reply via email to