coderabbitai[bot]
commented
3 months ago Walkthrough
The recent modifications to the FFmpeg decoder enhance video frame processing by implementing a mechanism to request IDR frames when a specified threshold of frames is exceeded. By introducing a new constant and a counter for frames since the last IDR, the decoder improves its ability to handle frame corruption, ensuring more stable and higher-quality video playback.
Changes
| Files | Change Summary |
|---|---|
Streaming/FFmpegDecoder.cpp, Streaming/FFmpegDecoder.h |
Added MAX_DELAY_BETWEEN_IDR_FRAMES constant and framesSinceLastIDR variable to improve IDR frame management and overall decoding stability. |
Poem
🐇
In the land of frames so bright,
We count each one with delight.
If too many pass by my way,
An IDR frame I shall say!
Hopping through scenes, clear and fast,
Stability's here, at long last!
🎥
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
BradyBrenot
sonarcloud[bot]
TheElixZammuto
To mitigate #117 (Compression artifacts forming when left on the same scene for a while), request an IDR frame from the host every 1000 packets. This seems to reset the decoder well enough to completely avoid slow corruption problem, but shouldn't add too much extra bandwidth.
Unless I'm missing something, Sunshine never sends I or IDR frames after initially establishing the stream unless it's specifically asked to by the client.
(This is a hacky mitigation, not a proper fix. It works but it's not the ideal fix. Since this only seems to happen on this platform, I'm guessing either we're touching memory we shouldn't / in a way we shouldn't, or ffmpeg has a hardware acceleration bug on this platform. Tracking down the root cause is a pain though, especially with UWP's limitations)
Summary by CodeRabbit
New Features
Bug Fixes