Closed Bug 1677216 Opened 11 months ago Closed 2 months ago

WebRTC incoming video not displayed

Categories

(Core :: WebRTC: Audio/Video, defect, P5)

78 Branch
defect

Tracking

()

RESOLVED INVALID

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.

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

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

Component: Untriaged → Widget: Gtk
Flags: needinfo?(daniel)
Product: Firefox → Core

Mike, I guess you may be interested here.

I guess other video playback is ok, right?

Component: Widget: Gtk → Audio/Video: Playback
Priority: -- → P3

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.

Flags: needinfo?(daniel) → needinfo?(clara.guerrero)
Priority: P3 → P5

Hi, I tried this on x64-based processor (Intel).
Let me know if you need additional information.
Thanks!

Flags: needinfo?(clara.guerrero)

Moving to the correct component, for non-WebRTC video works fine.

Component: Audio/Video: Playback → WebRTC: Audio/Video

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Priority: P5 → --
Severity: -- → S4
Priority: -- → P5

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

Flags: needinfo?(daniel)

Sorry wrong NI there.

Flags: needinfo?(daniel) → needinfo?(stransky)

Yes, sorry.

Flags: needinfo?(stransky)

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+1
libnspr4-dev 2:4.29-1
bpo10+1
libnss3:ppc64el 2:3.60-1bpo10+1
libnss3-dev:ppc64el 2:3.60-1
bpo10+1
libvpx-dev:ppc64el 1.9.0-1bpo10+1
libvpx5:ppc64el 1.7.0-3+deb10u1
libvpx6:ppc64el 1.9.0-1
bpo10+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.

Flags: needinfo?(mh+mozilla)

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

Flags: needinfo?(mh+mozilla) → needinfo?(daniel)

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.

Flags: needinfo?(daniel)

try removing nspr, then removing nspr and nss, then removing vpx.

Flags: needinfo?(daniel)

Closing this as INVALID, please let us know if we can help, but this seems like an issue downstream.

Status: UNCONFIRMED → RESOLVED
Closed: 2 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.