Enable WebRTC HW H.264 on Flame KitKat

RESOLVED FIXED

Status

()

Core
WebRTC
P3
minor
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: diego, Unassigned)

Tracking

unspecified
ARM
Gonk (Firefox OS)
Points:
---
Dependency tree / graph
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [h264][vendor])

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
As per bug 1068394 comment 33 WebRTC H.264 hardware codec has not been enabled on Flame KitKat builds.
(Reporter)

Comment 1

4 years ago
Francis,

Can you work with T2M to ensure they include all the CAF prefs [1] in their partner prefs file?

[1] https://www.codeaurora.org/cgit/quic/lf/b2g/build/tree/gaia_settings/distribution/partner-prefs.js?h=v2.0#n29
Flags: needinfo?(frlee)
(Reporter)

Comment 2

4 years ago
[Blocking Requested - why for this release]:

WebRTC H.264 is a product requirement for v2.0.
blocking-b2g: --- → 2.0?
(Reporter)

Updated

4 years ago
Blocks: 1041241

Updated

4 years ago
Component: WebRTC: Audio/Video → Vendcom
Product: Core → Firefox OS

Comment 3

4 years ago
hi Diago,

Wesly is working with T2M for it, please wait for his update.

hi Wesly,

please double check with T2M that comment 1 will be all included in the next v2.0 release
Flags: needinfo?(frlee) → needinfo?(wehuang)

Comment 4

4 years ago
got it, I will include this into the req./bug list that I'm following with T2M.
Flags: needinfo?(wehuang)
(Reporter)

Comment 5

4 years ago
(In reply to Wesly Huang from comment #4)
> got it, I will include this into the req./bug list that I'm following with
> T2M.

Wesly,

Which bug is this?
Flags: needinfo?(wehuang)

Comment 6

4 years ago
Hi Diego, please help correct me if I'm wrong. 

My understanding is, if T2M has follow your suggestion in comment#1 (to include all the CAF prefs in their prefs file) then it will enable WebRTC HW H.264 on coming Flame KitKat release, so I put this as one requirement in the "wish list" (in which I consolidated different issues/requests) for the coming Flame KK release from T2M. T2M is going to release the SW Sep./30 today so maybe you can help check if it works later?
Flags: needinfo?(wehuang)
(Reporter)

Comment 7

4 years ago
(In reply to Wesly Huang from comment #6)
> Hi Diego, please help correct me if I'm wrong. 
> 
> My understanding is, if T2M has follow your suggestion in comment#1 (to
> include all the CAF prefs in their prefs file) then it will enable WebRTC HW
> H.264 on coming Flame KitKat release

Correct

> T2M is going to release the SW Sep./30
> today so maybe you can help check if it works later?

I don't have a Flame device at the moment.
(Reporter)

Comment 8

4 years ago
Nils,

Given you've encountered this problem before, could you help us verify if/when a new Flame build is supposed to have it enabled?
Flags: needinfo?(drno)
Not really a blocker in terms of shipping the release, but we do want to verify after t2M  has released the latest codebase and this blocks QA testing.

Please marks this as Resolved WFM once tested on latest software by T2M.
blocking-b2g: 2.0? → 2.0+
Whiteboard: POVB
I followed the instructions from https://bugzilla.mozilla.org/show_bug.cgi?id=1068394#c13

For your convenience:

adb root
adb remount
adb pull  /system/b2g/defaults/pref/user.js

Add the following line to the end of the file:
pref("media.peerconnection.video.h264_enabled", true);

adb push user.js /system/b2g/defaults/pref/user.js

I'm not 100% sure, but I think you need to do an

adb reboot

To make this change take effect. So these are the steps to manually enable H.264 on a device with the Flame KitKat build.

I assume that you would have to add the pref line from above to the user.js as part of your build to get it enabled in your own builds, if that's what you are asking for.
Flags: needinfo?(drno)

Comment 11

4 years ago
Hi Diego and Nils: the v184 SW, which expected to fix this issue, is just released. Would you help give it a try? Thank you.
Flags: needinfo?(dwilson)
Flags: needinfo?(drno)
(Reporter)

Comment 12

4 years ago
I think it would make more sense for a Mozilla dev to verify this.
Flags: needinfo?(dwilson)

Comment 13

4 years ago
Thanks Diego's reminder! Just realized you are in our partner's company instead of Mozilla, sorry :)

@Nils: may I have your support here? My understanding is, the steps mentioned in comment#10 is only needed if "WebRTC HW H.264" is not enabled in build, however now we expect T2M has made it in v184 by default (with comment#1's suggestion) so those steps are not needed anymore, and you'll be able to perform those tests (maybe H.264 video call? per my limited understanding of bug#1068394) which depends on "enabled-WebRTC HW H.264".

Thanks.
I just flashed a device just with the v184 image and made a WebRTC call. H264 is offered as video codec without any modifications needed on the device.
Flags: needinfo?(drno)
Interestingly the working partner pref gets over written if I put a Mozilla gaia/gecko on top of the v184 base image.

Comment 16

4 years ago
Thanks Nils! Thanks for the good news and pointed the interested thing out!
BTW would you let me learn by which ways to find partner pref. is over-written by flashing gaia/gecko? 
 
@Diego:

Would like to get your comment since you reported this issue, per Nils' result in comment#14 do you think it's enough to say T2M has enabled WebRTC HW H.264 on Flame KitKat v184 now?

Another thing is if it makes sense from your view that pref. will get over written after shallow flash gaia/gecko? Thanks.

Thank you.
Flags: needinfo?(dwilson)
Flags: needinfo?(drno)
(Reporter)

Comment 17

4 years ago
(In reply to Nils Ohlmeier [:drno] from comment #15)
> Interestingly the working partner pref gets over written if I put a Mozilla
> gaia/gecko on top of the v184 base image.

Randell,

Is there any way we can turn on WebRTC H.264 in a flame specific prefs file for Mozilla builds?
Flags: needinfo?(dwilson) → needinfo?(rjesup)
(In reply to Diego Wilson [:diego] from comment #17)
> Is there any way we can turn on WebRTC H.264 in a flame specific prefs file
> for Mozilla builds?

I think the problem here is that we would only want to do that for devices which we know have proper H.264 support. So we would need to check which device we are running on, and based on that turn H.264 on or off.
(In reply to Wesly Huang from comment #16)
> Thanks Nils! Thanks for the good news and pointed the interested thing out!
> BTW would you let me learn by which ways to find partner pref. is
> over-written by flashing gaia/gecko? 

Instead of trying to locate the pref file on the device or in the image I ended up making test calls with my H.264 enabled desktop browser and manually checking that H.264 got chosen in the SDP offer/answer (that was just quicker for me -- although checking the files is certainly easier and quicker if you know where they are on the device).
Flags: needinfo?(drno)
(Reporter)

Comment 20

4 years ago
(In reply to Nils Ohlmeier [:drno] from comment #18)
> (In reply to Diego Wilson [:diego] from comment #17)
> > Is there any way we can turn on WebRTC H.264 in a flame specific prefs file
> > for Mozilla builds?
> 
> I think the problem here is that we would only want to do that for devices
> which we know have proper H.264 support. So we would need to check which
> device we are running on, and based on that turn H.264 on or off.


The current official Flame build (KitKat) formally supports WebRTC H.264.

Comment 21

4 years ago
Thanks Nils and Diego, so based on comment#20 should we say this issue can be closed, since finally we enabled H.263 as intended?

And to Nils' finding, maybe new another issue to track?
Flags: needinfo?(dwilson)
Flags: needinfo?(drno)
(Reporter)

Comment 22

4 years ago
(In reply to Wesly Huang from comment #21)
> Thanks Nils and Diego, so based on comment#20 should we say this issue can
> be closed, since finally we enabled H.263 as intended?
> 
> And to Nils' finding, maybe new another issue to track?

It appears WebRTC H.264 is enabled on the vendor Flame builds but not on Mozilla's new Flame kitkat builds of gecko and gaia. I'm hoping :jesup can help us out here.
Flags: needinfo?(dwilson)

Comment 23

4 years ago
Thanks Diego! So at least I should remove this one from the list following with T2M for now.
(In reply to Wesly Huang from comment #21)
> Thanks Nils and Diego, so based on comment#20 should we say this issue can
> be closed, since finally we enabled H.263 as intended?
> 
> And to Nils' finding, maybe new another issue to track?

Sure. Sounds good to me.
Flags: needinfo?(drno)

Comment 25

4 years ago
According to comment 22, change the component.
Component: Vendcom → WebRTC
Product: Firefox OS → Core

Comment 26

3 years ago
Wesly, any update?
Flags: needinfo?(wehuang)

Comment 27

3 years ago
Can we ask T2M to know if it is enabled in 18D?

Comment 28

3 years ago
Kevin, sorry for late as this is one is out of my radar for a while.

This is enabled since Flame base image v184 (released on Oct./2 internally) and verified per comment#20, so still valid for v188 and latest v18D base image SW.

remove POVB from whiteboard to align the component change in comment#25.
Flags: needinfo?(wehuang)
Whiteboard: POVB

Comment 29

3 years ago
[Blocking Requested - why for this release]:

Hi Wesly,
Do we still need this on 2.0 or we should nominate this in m/c?
Thanks!
blocking-b2g: 2.0+ → 2.0?
Flags: needinfo?(wehuang)
The prefs are set in https://www.codeaurora.org/cgit/quic/lf/b2g/build/tree/gaia_settings/distribution/partner-prefs.js?h=v2.0#n29 so I'm not sure whether we keep them in our pvt builds when we ship OTAs.

A better place would be in the device tree like we did on tarako (see dev-pref.js in https://git.mozilla.org/?p=external/sprd-aosp/device/sprd.git;a=tree;f=sp6821a_gonk;h=8820b86c63290693b1713dd34b4cf750d26ee636;hb=refs/heads/sprdb2g_gonk4.0_6821/).
(In reply to Fabrice Desré [:fabrice] from comment #30)
> The prefs are set in
> https://www.codeaurora.org/cgit/quic/lf/b2g/build/tree/gaia_settings/
> distribution/partner-prefs.js?h=v2.0#n29 so I'm not sure whether we keep
> them in our pvt builds when we ship OTAs.
Noaki, or someone in QA is going to verify this and respond back..
> 
> A better place would be in the device tree like we did on tarako (see
> dev-pref.js in
> https://git.mozilla.org/?p=external/sprd-aosp/device/sprd.git;a=tree;
> f=sp6821a_gonk;h=8820b86c63290693b1713dd34b4cf750d26ee636;hb=refs/heads/
> sprdb2g_gonk4.0_6821/).
Flags: needinfo?(nhirata.bugzilla)
Diego, would this be in an external tree you control?
Flags: needinfo?(rjesup) → needinfo?(dwilson)
(Reporter)

Comment 33

3 years ago
(In reply to Randell Jesup [:jesup] from comment #32)
> Diego, would this be in an external tree you control?

I'd like to enable it on Mozilla Flame builds.
Flags: needinfo?(dwilson)
(Reporter)

Updated

3 years ago
Flags: needinfo?(rjesup)
Diego - see fabrice's comment 30 - "A better place would be in the device tree like we did on tarako" and a pointer to a commit to external/sprd-aosp/device/sprd.git (instead of https://www.codeaurora.org/cgit/quic/lf/b2g/build/tree/gaia_settings/distribution/partner-prefs.js?h=v2.0#n29)
Flags: needinfo?(rjesup)
(Reporter)

Comment 35

3 years ago
I see. So you and Fabrice are suggesting I enable it in somewhere like here?

https://www.codeaurora.org/cgit/quic/la/platform/vendor/qcom/msm8610/tree
(In reply to Diego Wilson [:diego] from comment #35)
> I see. So you and Fabrice are suggesting I enable it in somewhere like here?
> 
> https://www.codeaurora.org/cgit/quic/la/platform/vendor/qcom/msm8610/tree

Yes, I believe so (NI fabrice to verify)
Flags: needinfo?(fabrice)
Created attachment 8566317 [details]
greprefs.js

I think Fabrice is right.  We should probably have this device specific since it could vary from device to device.

in the /system/b2g/omni.ja
there is a greprefs.js:
within that pref, it shows different values than those that are listed in the suggested file

See attachment for the values that the current release build holds for flame-kk
Flags: needinfo?(nhirata.bugzilla)
(In reply to Diego Wilson [:diego] from comment #35)
> I see. So you and Fabrice are suggesting I enable it in somewhere like here?
> 
> https://www.codeaurora.org/cgit/quic/la/platform/vendor/qcom/msm8610/tree

Yep, this is where this belongs!
Flags: needinfo?(fabrice)

Comment 39

3 years ago
(In reply to Josh Cheng [:josh] from comment #29)
> [Blocking Requested - why for this release]:
> 
> Hi Wesly,
> Do we still need this on 2.0 or we should nominate this in m/c?
> Thanks!

Hi Josh:

per comment#9 and comment#22 I think we are ready to remove the nom., will do that in next 2.0 Triage.

@Fabrice:

May I understand comment#38 as "we don't need to put this
Flags: needinfo?(wehuang)

Comment 40

3 years ago
sorry for redundant content in comment#39, I have no question to Fabrice.

[Triage]

de-nom. from 2.0. Per comment#39.
blocking-b2g: 2.0? → ---

Updated

3 years ago
Severity: normal → minor
Flags: firefox-backlog+
Priority: -- → P3
Whiteboard: [h264][vendor]
(Reporter)

Comment 41

3 years ago
> (In reply to Diego Wilson [:diego] from comment #35)
> > I see. So you and Fabrice are suggesting I enable it in somewhere like here?
> > 
> > https://www.codeaurora.org/cgit/quic/la/platform/vendor/qcom/msm8610/tree
> 
> Yep, this is where this belongs!

I this that's reasonable. I don't believe there is any msm8610 release planned in the near future. However, I can make sure that future CAF releases have this enabled.

Unless there's any objections I'm fine with closing this bug.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.