Closed
Bug 1073025
Opened 10 years ago
Closed 10 years ago
Enable WebRTC HW H.264 on Flame KitKat
Categories
(Core :: WebRTC, defect, P3)
Tracking
()
RESOLVED
FIXED
People
(Reporter: diego, Unassigned)
References
Details
(Whiteboard: [h264][vendor])
Attachments
(1 file)
(deleted),
application/x-javascript
|
Details |
As per bug 1068394 comment 33 WebRTC H.264 hardware codec has not been enabled on Flame KitKat builds.
Reporter | ||
Comment 1•10 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•10 years ago
|
||
[Blocking Requested - why for this release]:
WebRTC H.264 is a product requirement for v2.0.
blocking-b2g: --- → 2.0?
Reporter | ||
Updated•10 years ago
|
Blocks: CAF-v2.0-CC-metabug
Updated•10 years ago
|
Component: WebRTC: Audio/Video → Vendcom
Product: Core → Firefox OS
Comment 3•10 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•10 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•10 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•10 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•10 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•10 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)
Comment 9•10 years ago
|
||
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
Comment 10•10 years ago
|
||
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•10 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•10 years ago
|
||
I think it would make more sense for a Mozilla dev to verify this.
Flags: needinfo?(dwilson)
Comment 13•10 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.
Comment 14•10 years ago
|
||
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)
Comment 15•10 years ago
|
||
Interestingly the working partner pref gets over written if I put a Mozilla gaia/gecko on top of the v184 base image.
Comment 16•10 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•10 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)
Comment 18•10 years ago
|
||
(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•10 years ago
|
||
(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•10 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•10 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•10 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•10 years ago
|
||
Thanks Diego! So at least I should remove this one from the list following with T2M for now.
Comment 24•10 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?
Sure. Sounds good to me.
Flags: needinfo?(drno)
Comment 25•10 years ago
|
||
According to comment 22, change the component.
Component: Vendcom → WebRTC
Product: Firefox OS → Core
Comment 27•10 years ago
|
||
Can we ask T2M to know if it is enabled in 18D?
Comment 28•10 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•10 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)
Comment 30•10 years ago
|
||
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•10 years ago
|
||
(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)
Comment 32•10 years ago
|
||
Diego, would this be in an external tree you control?
Flags: needinfo?(rjesup) → needinfo?(dwilson)
Reporter | ||
Comment 33•10 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•10 years ago
|
Flags: needinfo?(rjesup)
Comment 34•10 years ago
|
||
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•10 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
Comment 36•10 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
Yes, I believe so (NI fabrice to verify)
Flags: needinfo?(fabrice)
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)
Comment 38•10 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!
Flags: needinfo?(fabrice)
Comment 39•10 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•10 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•10 years ago
|
Severity: normal → minor
Flags: firefox-backlog+
Priority: -- → P3
Whiteboard: [h264][vendor]
Reporter | ||
Comment 41•10 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.
Updated•10 years ago
|
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•