WebRTC incoming video not displayed
Categories
(Core :: WebRTC: Audio/Video, defect, P5)
Tracking
()
People
(Reporter: daniel, Unassigned, NeedInfo)
Details
User Agent: Mozilla/5.0 (X11; Linux ppc64le; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
I have two machines running Debian buster, one of them is x86 based (amd64) and the other is POWER9 (ppc64le).
Using the previous Firefox package from Debian, version 68.12.0esr-1~deb10u1 on both machines, everything was working.
Debian recently distributed Firefox 78.4.1esr-1~deb10u1 as a security update. This is working fine on the x86 system.
On the ppc64le system, when a WebRTC call is established, the box for incoming video remains blank. The incoming sound is audible and the outgoing video and sound are both received by the peer.
tcpdump shows that incoming video RTP packets are received on the ppc64le host. about:webrtc shows packet statistics too. It looks like the connection has been negotiated correctly but maybe there is some codec or rendering issue.
As it was working before, I feel this is a regression.
Actual results:
The box for incoming video remains blank. Tried both JSCommunicator and Jitsi Meet.
Expected results:
The picture from the peer's video stream should appear.
|
Reporter | |
Comment 1•4 years ago
|
||
This bug report was tested on a ppc64le system with a kernel compiled for 4k page size.
We also have a similar problem but not the same thing with the ppc64 kernel compiled for a 64k page size, it is a different bug and impacts Firefox 68 as well:
https://forums.raptorcs.com/index.php/topic,200.msg1463.html#msg1463
|
||
Comment 2•4 years ago
|
||
Hi,
Thanks for the report.
I've tried reproducing on my end, using Ubuntu 20.04.1 LTS, both 78.5.0esr (64-bit) and 85.0a1 (2020-11-18) (64-bit) but both cameras are working fine.
I will set a component for this in order to get the dev team involved.
(If the team feels it's an incorrect one please feel free to change it to a more appropriate one.)
If you can get a regression rage using mozregression it would be great:
Download the latest mozregression-gui.tar.gz file from the github releases (https://github.com/mozilla/mozregression/releases). Once the file is downloaded, extract it and run the mozregression-gui file in the mozregression-gui directory. Example:
tar xf mozregression-gui.tar.gz
mozregression-gui/mozregression-gui
Following steps are found here: https://mozilla.github.io/mozregression/quickstart.html
Also, please attach your about:support information.
Best,
Clara
|
||
Comment 3•4 years ago
|
||
Mike, I guess you may be interested here.
|
|
||
Comment 4•4 years ago
|
||
I guess other video playback is ok, right?
|
|
Reporter | |
Comment 5•4 years ago
|
||
Yes, playing a Youtube video or a similar non-WebRTC video is OK
In a WebRTC session, the incoming video box appears black. The controls (e.g. for fullscreen) are visible at the bottom of the box.
Clara, were you testing on ppc64 or another architecture? I only have the problem on ppc64, it works fine on x86.
|
|
||
Updated•4 years ago
|
|
|
||
Comment 6•3 years ago
|
||
Hi, I tried this on x64-based processor (Intel).
Let me know if you need additional information.
Thanks!
|
||
Comment 7•3 years ago
|
||
Moving to the correct component, for non-WebRTC video works fine.
|
||
Comment 8•3 years ago
|
||
The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.
|
||
Updated•3 years ago
|
|
|
||
Comment 9•3 years ago
|
||
(In reply to Martin Stránský [:stransky] from comment #3)
Mike, I guess you may be interested here.
Did you mean to cc or NI glandium?
|
|
Reporter | |
Comment 12•3 years ago
|
||
I tested the latest Debian backport:
firefox-esr_78.6.1esr-1~deb10u1_ppc64el.deb
and observed the same problem.
There have been some issues with applications compiled on a system with 64k page size not working correctly on a system with 4k page size. Therefore, I took the code from Git and compiled the package myself on the system where it runs. Therefore, the compiler is running under the kernel with 4k page size. This didn't resolve the issue. This is the commit I tried:
esr78/master
4173d165de764bdaee92becde3e271c2211b9521
tag: debian/78.6.1esr-1
For that build, I included the ~bpo10+1 suffix in debian/changelog
Then I tried another build without the ~bpo10+1 suffix. It required three other build-deps to be updated so I built backports of each of these and installed them:
libnspr4:ppc64el 2:4.29-1bpo10+1bpo10+1
libnspr4-dev 2:4.29-1
libnss3:ppc64el 2:3.60-1bpo10+1bpo10+1
libnss3-dev:ppc64el 2:3.60-1
libvpx-dev:ppc64el 1.9.0-1bpo10+1bpo10+1
libvpx5:ppc64el 1.7.0-3+deb10u1
libvpx6:ppc64el 1.9.0-1
With this build, using those three backported libs, with the following at the top of debian/changelog:
firefox-esr (78.6.1esr-1) unstable; urgency=medium
Using this build, the WebRTC calls work with video in both directions.
Therefore, there is some glitch in the way the backport build works or in the way dependencies are built in the backport build logic.
|
||
Comment 13•3 years ago
|
||
Can you tweak things around in debian/rules's SYSTEM_LIBS to determine which of nspr, nss or vpx fixes it? (note: if you remove nspr, you need to remove nss too).
|
|
Reporter | |
Comment 14•3 years ago
|
||
I think that when I did this, I tried vpx first, that didn't resolve the issue and then I added the others, nss and nspr. So I don't think vpx is at fault but I'm not 100% sure either.
Can you please tell me the exact permutations of SYSTEM_LIBS to test and I'll make these builds next week some time.
|
|
||
Comment 15•3 years ago
|
||
try removing nspr, then removing nspr and nss, then removing vpx.
|
|
||
Updated•3 years ago
|
|
|
||
Comment 16•3 years ago
|
||
Closing this as INVALID, please let us know if we can help, but this seems like an issue downstream.
Description
•