PIPELINE_ERROR_DECODE after a few seconds of low delay mode video playback
Reported by
and...@rainway.io,
May 1 2018
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36 Platform: 10452.74.0 Steps to reproduce the problem: 1. Download and install https://rainway.io/ on a Windows 10 PC, install at least one game from a platform like Steam. 2. Login at https://play.rainway.io/ on a Chromebook device, start the game. 3. The video and audio streams will play for few seconds to a minute before the video runs into PIPELINE_ERROR_DECODE What is the expected behavior? The stream should run uninterrupted as it does on Windows, Mac, and Linux. What went wrong? We are tracking this on our bug tracker https://github.com/RainwayApp/bug-tracker/issues/35 Users report that chrome://flags/#disable-accelerated-video-decode when enabled causes the issue not to happen. I can reproduce this on my Chromebook, and disabling hardware decoding indeed makes the error go away. However, this isn't an ideal solution, since it slows down video decoding. Did this work before? No Does this work in other browsers? Yes Chrome version: 66.0.3359.117 Channel: stable OS Version: 66.0.3359.137 Flash Version: We are seeking the video often to keep it at the live edge. Happy to provide more details or testing data, just let me know.
,
Jun 23 2018
,
Jun 25 2018
Does that stream always cause decoding to break on that device?
,
Jul 10
After some research on our end, the seeking was just masking the real problem. A sudden gap or jump in the decoder causes the entire media to fail. In our testing when using WebRTC data channels, we had an FMP4 chunk arrive and appended it. Right after, an FMP4 chunk for a previous timecode (what should have been appended first) arrived and we blocked it from being appended as it was before the last buffer. At that same time, a "PIPELINE_ERROR_DECODE: video decode error" throws on the MediaElement as the buffer we did append caused a gap in the data. There is no way to recover from this and the error doesn't provide us with information on if the chunk was bad. This doesn't seem like it should result in a fatal error and should be recovered by the decoder.
,
Dec 17
This appears to be a technical question now.
,
Dec 17
Hi @dougman This issue is still occurring in the latest versions in ChromeOS and only on ChromeOS. Desktop and mobile versions of Chrome show no such issues, and other browsers such as Firefox and Safari work fine. Disabling GPU acceleration on ChromeOS solves the problem.
,
Dec 17
=>hiroh for triage. This type of error doesn't come from gaps, it comes from decoding failures. In this case I'd guess a non-keyframe is being appended following something else that is not a keyframe or doesn't belong to the group. Possibly this is fixed in 71+ by pts/dts changes where we'll override what an app says is a keyframe based on what's actually in the stream. ... but since this only occurs on CrOS it might also just be a decoding issue.
,
Dec 18
Hi, what is the device you have used as Chromebook? |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by h...@andrew.im
, Jun 4 201826.0 MB
26.0 MB Download