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

RESOLVED FIXED in mozilla32

Status

()

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: itsay, Assigned: shell)

Tracking

(Blocks 1 bug)

unspecified
mozilla32
x86
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(feature-b2g:2.0)

Details

(Whiteboard: [ucid:WebRTC15,2.0, ft:webrtc][ft:multimedia-platform])

User Story

As a Firefox OS user, I want my WebRTC video calls to preserve my battery life so that I can talk for longer.

Attachments

(2 attachments, 2 obsolete attachments)

Reporter

Description

5 years ago
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.
Reporter

Updated

5 years ago
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]
Reporter

Updated

5 years ago
Reporter

Comment 1

5 years ago
Add engineering dependency bugs for this features.
Depends on: 911046, 969312, 984223, 941302

Comment 2

5 years ago
Posted image WebRTC External Codec(1.5).jpg (obsolete) —

Comment 3

5 years ago
Posted image WebRTC External Codec(Ideal).jpg (obsolete) —

Comment 4

5 years ago
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.
Reporter

Comment 5

5 years ago
941302 should block 984223 only.
No longer depends on: 941302
Reporter

Comment 6

5 years ago
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

Comment 7

5 years ago
Attachment #8392751 - Attachment is obsolete: true
Attachment #8392752 - Attachment is obsolete: true
Reporter

Updated

5 years ago
No longer depends on: 969312
Reporter

Updated

5 years ago
No longer depends on: 984223
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
Assignee

Updated

5 years ago
Whiteboard: [ucid:, 1.5, ft:webrtc] → [ucid:WebRTC11, 1.5, ft:webrtc]
Assignee

Updated

5 years ago
Whiteboard: [ucid:WebRTC11, 1.5, ft:webrtc] → [ucid:WebRTC15, ft:webrtc]

Updated

5 years ago
Depends on: 1000044
No longer blocks: 1003040
Depends on: 1003040
Reporter

Updated

5 years ago
Whiteboard: [ucid:WebRTC15, ft:webrtc] → [ucid:WebRTC15,2.0, ft:webrtc][ft:multimedia-platform
Blocks: Loopmov_1_1
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)
Depends on: 1002402
No longer depends on: 984215, 1000044
Reporter

Updated

5 years ago
Whiteboard: [ucid:WebRTC15,2.0, ft:webrtc][ft:multimedia-platform → [ucid:WebRTC15,2.0, ft:webrtc][ft:multimedia-platform]
Flags: in-moztrap?(pyang)
Assignee

Updated

5 years ago
feature-b2g: --- → 2.0
User Story: (updated)
Reporter

Updated

5 years ago
Depends on: 1003712
Component: General → WebRTC
Product: Firefox OS → Core
Target Milestone: --- → mozilla32
Assignee

Comment 12

5 years ago
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.
Flags: needinfo?(rlin)
Flags: needinfo?(rjesup)
We're waiting on them to finish their work before preffing it on in FxOS for Flame.
Flags: needinfo?(rjesup)
Do you have a plan to get a KK gonk baseline for the Flame?  That is a prereq.
Flags: in-moztrap?(pyang)
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.
Flags: needinfo?(frlee)
Assignee

Comment 17

5 years ago
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.
Flags: needinfo?(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.
Flags: needinfo?(frlee)
Hi Maire, 
Could you follow this one?
Flags: needinfo?(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.
Flags: needinfo?(sescalante)
Flags: needinfo?(mreavy)
Flags: needinfo?(frlee)
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
Flags: needinfo?(frlee)
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
Assignee

Updated

5 years ago
No longer depends on: 1003040
Assignee

Comment 25

5 years ago
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: 5 years ago
Flags: needinfo?(sescalante)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.