1519860 - Firefox 65.0b9 -webrtc showing partial remote video after performing block and unblock camera

Status: RESOLVED DUPLICATE of bug 1525230

(Core :: WebRTC, defect, P3)

Description

[ychoo]

Attachment: User A wireshark and mozilla debug log

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

1. User A performs video call to user B with 720p camera
2. After two way videos, user A block camera and then unblock camera, i.e. disable local video track and re-enable local video track

Note: Both calls are connected to a media server

Actual results:

After user A unblock camera, both users show receive remote video correctly

Expected results:

After user A unblock camera, user A receives a portion of the remote video @ 180p instead of full video @ 720p

Media server video port 6230
Firefox User A video port 64276

From analyzing both video packets and Firefox debug logs, it appears that after block/unblock, the client received key frames without packet lost, those frames are all 1280x720, but yet the logs still showed they are 320x180. The client started showing failed decoded frames for every frame it received after block, and then stopped showing this error message right after it received key frame, and then started showing failed decoded frames for every frame it received after unblock again and stopped showing this error message right after it received key frame.

Comment 1

[ychoo]

Corrections

Actual results:

After user A unblock camera, user A receives a portion of the remote video @ 180p instead of full video @ 720p

Expected results:

After user A unblock camera, both users show receive remote video correctly

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Thanks ychoo, I assume you mean "After user A unblock camera, user B receives a portion of the remote video @ 180p instead of full video @ 720p" ?

Note: Both calls are connected to a media server

Which media server? Does the problem appear without the media server (peer to peer)?

Comment 3

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Nils, what do you think about the wrong resolution packets and decode errors? A bug in the media server?

Comment 4

[ychoo]

It is a commercial media server. Our calls are routed to the media server. We've verify the resolution sent by the media server did not change from 720p, but Firefox reported the video resolution changes to 180p after having problem with decoding some frames.

Comment 5

[Byron Campen [:bwc]]

So, the decode errors are happening because the decoder is being reset, likely as a result of the renegotiation.

The webrtc.org code definitely thinks that the frames coming in are 320x180, so if those frames really are 1280x720, this is likely either an openh264 issue, or a webrtc.org issue.

Dan, any ideas?

Comment 6

[Byron Campen [:bwc]]

Does this happen with Firefox 64?

Comment 7

[Nils Ohlmeier [:drno]]

I think this is probably a duplicate of bug 1520200.

Comment 9

[Jean-Yves Avenard [:jya]]

Actually, reading the des again, it's different. No decoding error would occur with the other bug

Comment 10

[Nils Ohlmeier [:drno]]

ychoo could please double check if the problem persists if you set media.navigator.mediadatadecoder_h264_enabled and media.navigator.mediadatadecoder_vpx_enabled to false?
Feel free to switch only one of them if you know which video codec is in use.

Comment 11

[ychoo]

Unfortunately the media server that we use is optimized for H.264.

Comment 12

[Jean-Yves Avenard [:jya]]

(In reply to ychoo from comment #11)

Unfortunately the media server that we use is optimized for H.264.

can you still try going into about:config, search for the preference media.navigator.mediadatadecoder_h264_enabled and toggle it from true to false and then go back to your test page and try again. see if that fixes it.

Additionally, if you could check that the issue is fixed in Firefox Nightly (available at https://www.mozilla.org/en-US/firefox/channel/desktop/)

thank you.

Comment 13

[Nils Ohlmeier [:drno]]

Most likely this was a duplicate of bug 1525230.

Feel free to re-open if this is still an issue.