[Webkit-unassigned] [Bug 183331] New: [webrtc] Receiving an IDR frame under packet loss conditions can cause unrecoverable video distortions

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=183331

            Bug ID: 183331
           Summary: [webrtc] Receiving an IDR frame under packet loss
                    conditions can cause unrecoverable video distortions
           Product: WebKit
           Version: Safari 11
          Hardware: All
                OS: All
            Status: NEW
          Severity: Major
          Priority: P2
         Component: WebRTC
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: andj2223 at gmail.com
                CC: youennf at gmail.com

Using Safari on the desktop, do the following:
1. Visit the example url at <redacted> and log in with <redacted> username/password. (Youenn, check your email for this info, and any other devs that want it just let me know.)
2. Once you're logged in, you should see a character spinning around. Packet loss is being simulated at 10% on the server, so there is no need for you to do so locally.
3. Press alt+i. This will send an IDR to you. You may notice corruption/distortion right away, but if you don't, just keep pressing alt+i. It should only take 6-7 keypresses to reproduce the distortion. You can confirm that your keypress is being registered by looking for the "!!! REQUESTING IDR !!!" message in the web inspector console.

Actual behavior: This distortion is not corrected within a reasonable time, and stays around for quite a while.
Expected behavior: Either no distortion at all, or very brief distortion that gets corrected.

This ends up being quite a serious issue, because any packet loss that occurs during an IDR can cause permanent corruption and distortions in the video stream.

Notes:
* Note I use out-of-band SPS/PPS with this example via the SDP sprop-parameter-sets parameter. The problem also occurs with in-band SPS/PPS. The purpose of delivering SPS/PPS out-of-band over a reliable transport for this repro is to completely eliminate SPS/PPS nalu packet corruption as a potential source of the problem, so we can focus on where the real issue is -- probably a problem in the code that handles lost packets of an IDR slice.
* The problem also occurs on iOS devices, but there isn't a convenient hotkey to use to send IDR on iOS. To replicate the problem on iOS, perform steps 1-2 on a desktop and leave the page open, then perform steps 1-2 on an iOS device. Now, with both devices consuming the same stream, you can press Alt+i on the desktop  and the IDR will be sent to the iOS device, where you should notice the same kind of corruption happening.
* The problem does not occur when there is not packet loss.
* The issue also occurs in Chrome, so the problem may be within libwebrtc.
* There is also a slightly related issue filed on the webrtc project, https://bugs.chromium.org/p/webrtc/issues/detail?id=8423 HOWEVER, I believe they are currently a bit confused about the real source of the problem -- They seem to think the issue is being caused by lost SPS/PPS, whereas I'm using an out-of-band SPS/PPS here. The problem is therefore more likely caused by a mishandling of lost IDR frame packets and doesn't have anything to do with lost SPS/PPS. So the 8423 issue is useful reading, but can also be a bit confusing due to the "lost SPS/PPS" (unintentional) red herring. I've updated 8423 with notes trying to convince them to look more deeply into the lost IDR packet problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180305/033c838d/attachment-0001.html>