1073025 - Enable WebRTC HW H.264 on Flame KitKat

Status: RESOLVED FIXED

(Core :: WebRTC, defect, P3)

Description

[Diego Wilson [:diego]]

As per bug 1068394 comment 33 WebRTC H.264 hardware codec has not been enabled on Flame KitKat builds.

Comment 1

[Diego Wilson [:diego]]

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

Comment 2

[Diego Wilson [:diego]]

[Blocking Requested - why for this release]:

WebRTC H.264 is a product requirement for v2.0.

Comment 3

[Francis Lee [:frlee]]

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

Comment 4

[Wesly Huang (EPM)]

got it, I will include this into the req./bug list that I'm following with T2M.

Comment 5

[Diego Wilson [:diego]]

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

Comment 6

[Wesly Huang (EPM)]

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?

Comment 7

[Diego Wilson [:diego]]

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

Comment 8

[Diego Wilson [:diego]]

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?

Comment 9

[bhavana bajaj [:bajaj]]

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.

Comment 10

[Nils Ohlmeier [:drno]]

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.

Comment 11

[Wesly Huang (EPM)]

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.

Comment 12

[Diego Wilson [:diego]]

I think it would make more sense for a Mozilla dev to verify this.

Comment 13

[Wesly Huang (EPM)]

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.

Comment 14

[Nils Ohlmeier [:drno]]

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.

Comment 15

[Nils Ohlmeier [: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

[Wesly Huang (EPM)]

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.

Comment 17

[Diego Wilson [:diego]]

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

Comment 18

[Nils Ohlmeier [:drno]]

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

Comment 19

[Nils Ohlmeier [:drno]]

(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).

Comment 20

[Diego Wilson [:diego]]

(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

[Wesly Huang (EPM)]

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?

Comment 22

[Diego Wilson [:diego]]

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

Comment 23

[Wesly Huang (EPM)]

Thanks Diego! So at least I should remove this one from the list following with T2M for now.

Comment 24

[Nils Ohlmeier [:drno]]

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

Comment 25

[Ken Chang[:kenkai]]

According to comment 22, change the component.

Comment 26

[Kai-Chih Hu [:khu]]

Wesly, any update?

Comment 27

[Kai-Chih Hu [:khu]]

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

Comment 28

[Wesly Huang (EPM)]

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.

Comment 29

[Josh Cheng [:josh]]

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

Comment 30

[[:fabrice] Fabrice Desré]

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/).

Comment 31

[bhavana bajaj [:bajaj]]

(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/).

Comment 32

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

Diego, would this be in an external tree you control?

Comment 33

[Diego Wilson [:diego]]

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

Comment 34

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

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)

Comment 35

[Diego Wilson [:diego]]

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

Comment 36

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

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

Comment 37

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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

Comment 38

[[:fabrice] Fabrice Desré]

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

Comment 39

[Wesly Huang (EPM)]

(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

Comment 40

[Wesly Huang (EPM)]

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

[Triage]

de-nom. from 2.0. Per comment#39.

Comment 41

[Diego Wilson [:diego]]

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