One of VP9 stream freeze after decoding a while
Reported by
brightc...@gmail.com,
May 22 2018
|
|||||||||||
Issue descriptionChrome Version : 67.0.3396.48 URLs (if applicable) : OS version : Windows Network (such as Cable/DSL/Dial up etc): LAN Audio/Video format (if applicable): VP9 Special chrome flags (if applicable): Behavior in Safari (if known): Behavior in Firefox (if known): Video issue, Audio issue, both, neither? Video issue <b>Flash or HTML5? <right-clicking most players will either reveal some text</b> with “Flash”; otherwise likely HTML5> If the browser or renderer crashed (“Aw, Snap”), please add any crash IDs from chrome://crashes (possibly after enabling crash reporting per http://support.google.com/chrome/bin/answer.py?hl=en&answer=96817) What steps will reproduce the problem? (1) WebRTC receive many VP9 streams (2) After a while, one of VP9 stream freezed (3) What is the expected result? The stream should not freeze What is the actual result? One of vp9 stream is freeze Any additional information (anything else which may help us debug the issue)? 1. When failed, the chrome log output the following errors till this stream is delete: Failed to decode frame with timestamp 3475690646, error code: -1 2. If delete and readd this stream again with setlocal/setremotedescription, the stream can be decoded again for a while 3. This copy of stream can be decoded by another when the problem occured Please attach the HTML5/JavaScript code or audio/video files as well as screenshot and/or videos (if applicable)
,
May 22 2018
Will need a lot more details to triage this. =>WebRTC+VP9 folks
,
May 23 2018
Hello All, when the streams use VP8, there are no any problems. I wonder, 1. if the vp9 decoder failed for a stream long time (not due to lack of keyframe), why there is no reset action? 2. The VP9 settings VP9E_SET_FRAME_PARALLEL_DECODING is off by default. If the incoming streams have one more vp9, or the vp9 is encoded with VP9E_SET_FRAME_PARALLEL_DECODING setting, are these related to or affected by this setting when decoding?
,
May 24 2018
brightcove@ - Thanks for filing the issue...!! Could you please provide a sample test file/url to test the issue from TE-end. This will help us in triaging the issue further. Thanks...!!
,
May 25 2018
@krajshree@chromium.org, I will try to setup an environment that you can access by Internet. The VP9 decode freezing problem did not appear always, but under the lower resolution(<=640*360) it is more easy to appear.
,
May 25 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 25 2018
@krajshree@chromium.org, The VP9 freezing problem occured more easy at 640*360 resolution. JP
,
May 25 2018
brightcove@ Thanks for the update. As per comment #5, request you to provide sample file/URL which will help in further triaging of the issue. Thanks..
,
May 25 2018
,
May 25 2018
Hello All, The attached is the recorded VP9 stream by wireshark, it can be replay with ./video_replay -input_file ~/Desktop/l.rtpdump -codec VP9 -payload_type 98 -red_payload_type 106 -ssrc 98902273. This stream is coded at 640*360 resolution, while the stream coded with other resolution rarely caused problem.
,
May 25 2018
I analyzed the dump. The video bitstream is indeed broken. vpxdec -o out.yuv -k --i420 ./recv_0x7fc9d0836c00.ivf Warning: Failed to decode frame 47: Corrupt frame detected Warning: Additional information: Failed to decode tile data Warning: Additional information: Keyframe / intra-only frame required to reset decoder state ... Warning: Failed to decode frame 345: Corrupt frame detected Warning: Additional information: Failed to decode tile data But there is no issue in RTP stream: - no gaps in sequence numbers - no gaps in picture id This means that broken video bitstream was wrapped into RTP. If there is no middle box (SFU) which does repacketization then I would blame sender/encoder. brightcove@, What kind of encoder are you using? Could you record its output and try to decode it with vpxdec and see if it fails?
,
May 26 2018
@ssilkin@chromium.org, Thank you. This stream is transcoded from H264, re-encode with libvpx in SFU. The VP9 stream coded by chrome sometimes also freeze, I will try to catch it.
,
Jul 9
I'm closing this. Please reopen if you find issue with chrome sender. |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by sindhu.chelamcherla@chromium.org
, May 22 2018