Closed Bug 984239 Opened 7 years ago Closed 6 years ago
[meta][user story] Adding H264 hardware support to Web
RTC in Firefox OS
As a Firefox OS user, I want my WebRTC video calls to preserve my battery life so that I can talk for longer.
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.
Summary: Adding H264 hardware support to WebRTC in Firefox OS → [meta][user story] Adding H264 hardware support to WebRTC in Firefox OS
Whiteboard: [ucid:, 1.5, ft:webrtc]
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.
941302 should block 984223 only.
No longer depends on: 941302
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!
Assignee: nobody → rlin
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
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).
No longer depends on: 970725
Whiteboard: [ucid:, 1.5, ft:webrtc] → [ucid:WebRTC11, 1.5, ft:webrtc]
Whiteboard: [ucid:WebRTC11, 1.5, ft:webrtc] → [ucid:WebRTC15, ft:webrtc]
Whiteboard: [ucid:WebRTC15, ft:webrtc] → [ucid:WebRTC15,2.0, ft:webrtc][ft:multimedia-platform
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)
Whiteboard: [ucid:WebRTC15,2.0, ft:webrtc][ft:multimedia-platform → [ucid:WebRTC15,2.0, ft:webrtc][ft:multimedia-platform]
Component: General → WebRTC
Product: Firefox OS → Core
Target Milestone: --- → mozilla32
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.
We're waiting on them to finish their work before preffing it on in FxOS for Flame.
Do you have a plan to get a KK gonk baseline for the Flame? That is a prereq.
Hi Francis, Do you have the timeline for kk on flame?
Flags: needinfo?(rlin) → needinfo?(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.
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.
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.
Hi Maire, Could you follow this one?
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.
I mean could you be the assignees of this one?
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
Free it because of no action for this meta bug.
Assignee: rlin → nobody
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?
Assignee: nobody → sescalante
Moved the one open bug on this to 988276, since H264 support is added. so there is clarity that this is a feature now.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.