Looking at my Intel x86 Android device the OpenH264 codec is present however opening https://mozilla.github.io/webrtc-landing/pc_test.html and checking the require h264 checkbox results in "No H264 found in this offer!!" I suspect that we are shipping the ARM OpenH264 binary to Android x86 users.
IIUC, we only have one Android build for the plugin (ARM); we need x86 as well.
yes, only android arm was requested. I can get x86 builds done today hopefully. rail, can we distinguish the architectures from Balrog?
Flags: needinfo?(catlee) → needinfo?(rail)
Yes, we can. ARM uses Android_arm-eabi-gcc3 in the URL as tits build target, for example, and this is how we can pin Android to v1.3 while other targets point to v1.4
Kevin -- I'm looking for someone to test the x86 Android build. Catlee provided it in email to us. Can you test it? If you're having problems loading it, I'm sure Snorp can help. If anyone on this bug has an x86 Android device, I'd appreciate help testing.
This works on a Motorola Razr i XT890. Would like to test on a Galaxy Tab 3 as well before calling this done.
The 1.4 x86 build looks good on a Galaxy Tab 3 as well.
What's the status with this? Is the releng stuff fixed? Are we blocked on the 1.4 release for Android?
AFAIK there are no blockers from Releng. Just waiting for the go.
I believe that I am still getting the ARM version on a Motorola Razr i and Firefox for Android Nightly. Cleared data to get a fresh OpenH264 plugin download and at https://mozilla.github.io/webrtc-landing/pc_test.html I still get no h264 in offer.
Hmm, my RAZRi has become unusable lately (on Aurora), because I get a crash after browsing a few pages. about:crashes has a completely useless stack. Could this be the underlying reason?
(In reply to Gian-Carlo Pascutto [:gcp] from comment #10) > Hmm, my RAZRi has become unusable lately (on Aurora), because I get a crash > after browsing a few pages. about:crashes has a completely useless stack. > Could this be the underlying reason? Unlikely I'd imagine unless we do something with the plugin after downloading it. Normally we don't load OpenH264 unless we actually agree to use it in a call. I wouldn't quite say impossible (perhaps something in the download code is touching it, but I'd be surprised).
Is this fixed now?
Releng created x86 builds and enabled updates this works on OpenH264 1.4 and better.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.