984239 - [meta][user story] Adding H264 hardware support to WebRTC in Firefox OS

Status: RESOLVED FIXED

(Core :: WebRTC, defect)

Description

[Ivan Tsay (:ITsay)]

This user story is to add H.264 hardware support to WebRTC for Firefox OS. Since desktop level calls are needed for the phone<->desktop calls, H.264 software support (OpenH264 project') would be needed and it is addressed in bug 948160.

Comment 1

[Ivan Tsay (:ITsay)]

Add engineering dependency bugs for this features.

Comment 2

[u459114]

Attachment: WebRTC External Codec(1.5).jpg

Comment 3

[u459114]

Attachment: WebRTC External Codec(Ideal).jpg

Comment 4

[u459114]

Ivan,
If this user story is target for 1.5, I think you may remove some block issues.

Please refer to WebRTC External Codec(1.5).jpg and WebRTC External Codec(Ideal).jpg. For 1.5, only bug 911046 is a must landing issue.

Comment 5

[Ivan Tsay (:ITsay)]

941302 should block 984223 only.

Comment 6

[Ivan Tsay (:ITsay)]

Randy,

As we discussed, please help to adjust the dependency bug to this user story. Once it is done, please re-assign it back to me for the tracking. Thanks!

Comment 7

[u459114]

Attachment: WebRTC External Codec(1.5).jpg

Comment 8

[u459114]

Attachment: WebRTC External Codec(Ideal).jpg

Comment 9

[u459114]

Ivan,
Public the origin of these diagram, you may modify them according to status change
https://docs.google.com/a/mozilla.com/drawings/d/1OoCgWP-UbXEW9Mi06vfthLbt62eGH61g58a2PXuyjrs/edit?usp=sharing
https://docs.google.com/a/mozilla.com/drawings/d/1ZGje4S0H5bCJi644f57Eq2TLcBAXs-SYMga72XBzEVg/edit?usp=sharing

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

Bug 970725 definitely does not block landing a working H.264 implementation; the webrtc.org code will rescale camera video as needed in the CPU before encoding.  It is an (important) CPU-use optimization, especially when the not-yet-landed code for changing encode resolution in response to CPU load and bandwidth restrictions lands (bug 986513).

Comment 11

[Maire Reavy [:mreavy]]

Per the Wednesday (April 30th) meeting with CJ, Ivan, Randell, Romain, Shell & me
* Need 1002402 (which already landed)
* Need Bug 985253, Bug 996379 (which includes Bug 985254 - Randell drive) 
* Bug 984215 - should be removed as a dependency.  It will likely have only a small impact on performance and so it shouldn't block [Randell] - only under 2.0 bug
* Bug 1000044 (since it's audio) should be removed as a dependency for H.264 (it is a generic problem, no specific to H.264) and nominated as a simple blocker for v2.0/Fx32?
* Bug 1003040 is the meta but to capture remaining work needed to get H.264 turned on by default (so it should stay a blocker to this bug)

Comment 12

[:shell escalante]

Can we close this meta bug?  we've got 2 bugs still open tracking changes from the partner in firmware - but i believe we've checked in all the mozilla platform work for FxOS.

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

We're waiting on them to finish their work before preffing it on in FxOS for Flame.

Comment 14

[Michael Vines [:m1] [:evilmachines]]

Do you have a plan to get a KK gonk baseline for the Flame?  That is a prereq.

Comment 15

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Hi Francis, 
Do you have the timeline for kk on flame?

Comment 16

[Francis Lee [:frlee]]

hi Randy,

KK support needs to be done by T2M and it depends on QCT's CS release date. the targeted KK release will be M-E/July.

Comment 17

[:shell escalante]

Can we get an engineering build of KK with the latest QCT DSP build?  We're asking to not wait on the QCT final release - but get a early engineering only build in Mozilla on the Flame with the fixes that we needed (they are there) to test.

Comment 18

[Francis Lee [:frlee]]

hi All,

T2M has started to port Android KK with non-final QCT CS to gain some time ahead. the SOW has been signed with T2M, but the earliest date to receive Android KK is E/July (on the contract, but possibly to have it a bit earlier, i will keep you posted). Once we receive this Android KK build, we will still need to port it to FxOS v1.4.

Comment 19

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Hi Maire, 
Could you follow this one?

Comment 20

[Maire Reavy [:mreavy]]

Hi Randy,  What would you like me to follow?  Are you asking about the KK build that has all the DSP fixes for using the H.264 codec in WebRTC calls?

Shell has been working with Francis to track the KK build with the DSP fixes we need.  

Shell/Francis -- Is there any easy way to know/determine if a developer is using the KK build with the DSP fixes?  I remember dwilson saying there would be a version number for the ADSP (and he can give us the number), but I'm not sure how to find out the ADSP version number that's in a particular KK build.

Comment 21

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

I mean could you be the assignees of this one?

Comment 22

[Francis Lee [:frlee]]

hi All,

for KK v165 base image, the ADSP version is : 

ADSP.BF.2.4.6 	ADSP.BF.2.4.6-00002-M8610AAAAAAAZL-1 	adsp_proc 	BIN

Comment 23

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Free it because of no action for this meta bug.

Comment 24

[Maire Reavy [:mreavy]]

Randy --  I see what you're saying.  When this became a meta/tracking bug, someone should have unassigned it from you. 

Shell -- I know you're tracking this.  I think we can now close this bug now that we have the KK build with the H.264 fixes.  Do you agree?

Comment 25

[:shell escalante]

Moved the one open bug on this to 988276, since H264 support is added.  so there is clarity that this is a feature now.