GNOME Bugzilla – Bug 657950
ffmpegdec: post QoS messages when dropping a frame
Last modified: 2011-09-26 23:40:38 UTC
Note that I am not 100% certain the posting when setting ffmpeg to discard is totally correct. It just seems to most likely correct way to me, but depends on the exact ffmpeg semantics.
Created attachment 195398 [details] [review] ffmpegdec: post QoS messages when dropping a frame There seems to be a little bit of non obvious logic where the QoS logic can decide to not drop decoding a frame and pass it to ffmpeg, telling it to drop. In this case, the QoS logic does not drop the frame itself, but since the frame will end up being dropped, we still mark it as dropped and post a QoS message.
Comment on attachment 195398 [details] [review] ffmpegdec: post QoS messages when dropping a frame >+drop_qos: >+ { >+ GstClockTime stream_time, jitter, outtime; >+ ... >+ stream_time = >+ gst_segment_to_stream_time (&ffmpegdec->segment, GST_FORMAT_TIME, >+ outtime); outtime seems to be used ununinitialised here?
*** Bug 617023 has been marked as a duplicate of this bug. ***
Created attachment 197507 [details] [review] ffmpegdec: post QoS messages when dropping a frame There seems to be a little bit of non obvious logic where the QoS logic can decide to not drop decoding a frame and pass it to ffmpeg, telling it to drop. In this case, the QoS logic does not drop the frame itself, but since the frame will end up being dropped, we still mark it as dropped and post a QoS message.
Indeed. That code gets removed by the next patch to move that logic to libgstvideo, so I've updated that next patch as well.
Oh well, let's get it in: commit 8bf3d5a2b77eff15e130bde36366457c26b7f66a Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Thu Sep 1 16:46:47 2011 +0100 ffmpegdec: post QoS messages when dropping a frame There seems to be a little bit of non obvious logic where the QoS logic can decide to not drop decoding a frame and pass it to ffmpeg, telling it to drop. In this case, the QoS logic does not drop the frame itself, but since the frame will end up being dropped, we still mark it as dropped and post a QoS message. https://bugzilla.gnome.org/show_bug.cgi?id=657950 The 'live' bit is always FALSE now though, not sure that's entirely correct.
> The 'live' bit is always FALSE now though, not sure that's entirely correct. Nevermind that, that's fine, since it's about whether *dec syncs against a clock (and drops stuff because of that), and not about whether the pipeline/upstream is live.