GNOME Bugzilla – Bug 796771
videodecoder: Don't always drain on gaps/discont
Last modified: 2018-07-12 19:27:14 UTC
This drain was introduced by resolution of the following bug fix: https://bugzilla.gnome.org/show_bug.cgi?id=767232 The problem being that OMX and V4L2 only support draining in a way the reference frames are lost. There is also concerns about FFMPEG and VAAPI as it means reference frames, which are pushed as read/write, are being pushed. So in direct rendering, modication of these frames will cause decoding issues. In this bug report, it was also stated that this was needed for TRICKMODE_KEY_UNITS. In this mode, gaps and discont are very unlikely, though if they appears, skipping to the next immediatly is what one would expect.
Created attachment 372984 [details] [review] videodecoder: Don't always drain on gaps/discont V4L2 and OMX decoder don't support draining and keeping reference frames. As a side effect, these decoder just stops working on gaps/discont. When this drain was introduced, the commit stated that this was for TRICKMODE_KEY_UNITS, so only drain if running in this mode.
People have gone back and forth on this question a bit in the past. The problem with a discont is that you can't really guarantee anything about the following bytes - you don't know how large the discont was. It's *usually* a single packet, or some minor corruption, but in the worst case it can mean something much worse - for a H.264 bytestream for example, you can't guarantee that you didn't miss a new SPS/PPS and are supposed to be decoding a stream of a completely new resolution now. In the long term, I think we need to distinguish the 2 cases somehow - "best effort, safe to continue decoding after discont" and "all bets are off, better wait for the next IDR". For now, this seems fine.
Attachment 372984 [details] pushed as 62cb084 - videodecoder: Don't always drain on gaps/discont