1771101 - Receiving a playout-delay extension with value 0 freezes video

Status: NEW

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

Description

[lminiero]

Hi,

apparently, when Firefox receives a playout-delay extension where both values are 0, the incoming video becomes frozen. This seems to happen in particular when 0 is received either after a sequence of packets with no playout-delay extension is received, or when 0 is received after other values where received first. Video is not frozen when 0 is received right away, from the very first packet, but it gets frozen when values change and then get back to 0.

An easy way to replicate this is via the Janus VideoRoom demo:

1. open the demo: https://janus.conf.meetecho.com/videoroomtest
2. create a subscription to yourself, by typing this on the JS console: newRemoteFeed(myid)
3. tell Janus to send the extension with value 0, by typing this on the console: feeds[1].send({message: {request: "configure", mid: "1", min_delay: 0, max_delay: 0}});

Notice that feeds[1] will act upon the first subscription, so in case other users are trying the same demo, you may actually be enforcing the extension on a different subscription than the one you just created: the result will be the same, and will be the related video freezing.

Sending a new request to ask for a different playout-delay (e.g., 1) unfreezes the video, which seems to suggest that it's indeed 0 that's causing something to break (maybe something related to the internal jitter buffers?).

This was originally reported to us by a Mac user, but it seems independent of the OS, as we could replicate it on Linux as well. Please let me know if there's any other information I can provide to help.

Comment 1

[Jim Mathies [:jimm]]

Hey Byron, Jib suggested you might be able to debug this extension issue.

Comment 2

[Byron Campen [:bwc]]

I'm not sure why this would be. It is possible that this is an old libwebrtc bug that has since been fixed. Let me look into it.

Comment 3

[Jim Mathies [:jimm]]

Hooking this up to the fast forward tracker.

Comment 4

[Byron Campen [:bwc]]

So it looks like there have been some changes to the playout delay stuff in libwebrtc since the version we are using, but I have not found a smoking gun yet. ESR (91) works, so it may have been a regression from 1654112. I'm going to try a mozregression.

Comment 5

[Byron Campen [:bwc]]

Yeah, this definitely looks like a regression from bug 1654112.

16:12.98 INFO: No more inbound revisions, bisection finished.
16:12.98 INFO: Last good revision: c8fdcf75317d40a3ead539a959f748c940d0a5c9
16:12.98 INFO: First bad revision: 1495ca5ef535f8ad692a3a579ca42eddc14f39a8
16:12.98 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c8fdcf75317d40a3ead539a959f748c940d0a5c9&tochange=1495ca5ef535f8ad692a3a579ca42eddc14f39a8

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1654112

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1654112