GNOME Bugzilla – Bug 777094
videodecoder: Don't queue frames in TRICKMODE_KEY_UNITS
Last modified: 2018-05-04 12:42:50 UTC
See commit message
Created attachment 343249 [details] [review] videodecoder: Don't queue frames in TRICKMODE_KEY_UNITS When the input is TRICKMODE_KEY_UNITS, we expect to only receive keyframes which we want to decode/push immediately. Therefore don't queue them
Comment on attachment 343249 [details] [review] videodecoder: Don't queue frames in TRICKMODE_KEY_UNITS This probably breaks things if the decoder or upstream does not pass only keyframes because they don't support that.
Created attachment 343310 [details] [review] videodecoder: Don't queue frames in TRICKMODE_KEY_UNITS When the input is TRICKMODE_KEY_UNITS, we expect to only receive keyframes which we want to decode/push immediately. Therefore don't queue them
Created attachment 343314 [details] [review] videodecoder: Don't queue frames in TRICKMODE_KEY_UNITS When the input is TRICKMODE_KEY_UNITS, we expect to only receive keyframes which we want to decode/push immediately. Therefore don't queue them. If upstream didn't send just keyframes (which is the ideal situation), two different things can happen: 1) Either the subclass checks the segment flags and properly configures the decoder implementation to only decode/output keyframes, 2) Or the subclass really decodes and outputs everything, in which case the reverse frames will end up arriving "late" downstream (and will be dropped). If upstream did properly send GOP in reverse order, we still end up just showing keyframes (but at the overhead of decoding everything).
Review of attachment 343314 [details] [review]: OK
commit dfa548dc5b88d52e46c81d33d3f96193e68f8efe Author: Edward Hervey <edward@centricular.com> Date: Tue Jan 10 15:59:55 2017 +0100 videodecoder: Don't queue frames in TRICKMODE_KEY_UNITS When the input is TRICKMODE_KEY_UNITS, we expect to only receive keyframes which we want to decode/push immediately. Therefore don't queue them. If upstream didn't send just keyframes (which is the ideal situation), two different things can happen: 1) Either the subclass checks the segment flags and properly configures the decoder implementation to only decode/output keyframes, 2) Or the subclass really decodes and outputs everything, in which case the reverse frames will end up arriving "late" downstream (and will be dropped). If upstream did properly send GOP in reverse order, we still end up just showing keyframes (but at the overhead of decoding everything). https://bugzilla.gnome.org/show_bug.cgi?id=777094
lol, forgot to close it :D