the video is dislocated when the packet loss more than 20% using h264 codec in webrtc
Reported by
xpeng1...@gmail.com,
Dec 22 2017
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36 Example URL: Steps to reproduce the problem: 1. make a video call with h264 codec using webrtc and enable NACK 2. set the packet loss to more than 20% What is the expected behavior? the video should be normal or the image should be paused when the frame can not be decoded. What went wrong? the video is dislocated , you can check the fan in the image i uploaded. Did this work before? N/A Is it a problem with Flash or HTML5? N/A Does this work in other browsers? N/A Chrome version: 63.0.3239.84 Channel: n/a OS Version: 10.0 Flash Version: Contents of chrome://gpu:
,
Dec 28 2017
As this issue is related to H264 codec in webrtc and we need to set packet loss more than 20%, hence adding the label as TE-NeedsTriageHelp, can anyone from the Dev team please have a look at this issue Thanks!
,
Dec 28 2017
,
Jan 10 2018
,
Jan 12 2018
,
Jan 12 2018
ssilkin@ any chance you could have a look? Not sure if codec or maybe jitter buffer related?
,
Feb 2 2018
First, we don't expect the WebRTC bitrate adaptation to work well when there is 20% sustained packet loss. Having said that, we should never have the distortions that you captured in recv_pic.jpg. Most probably, the distortions are caused by https://bugs.chromium.org/p/webrtc/issues/detail?id=8423. Can you see if starting Chrome with the flag --force-fieldtrials="WebRTC-SpsPpsIdrIsH264Keyframe/Enabled/" removes the problem?
,
May 4 2018
Assigning to Philip since this is likely the same as webrtc/8423. |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by krajshree@chromium.org
, Dec 26 2017