Slow plugin skipping frames when needed

MathieuP mathieu.pierfitte at
Thu Nov 8 23:26:24 UTC 2018


I am currently working on a "slow" plugin, meant to analyze as many frames
of a live stream as possible and drop the rest to make sure I am not falling
behind. Let's say my hardware can deal with 10 frames per second and I have
a live stream of 30 FPS in input, I am looking for a way to keep only 1 out
of 3 frames. I want my plugin to be the driving force of this frame rate,
because I can't come up with a magic number for the frame rate that will
work on any PC / input video.

I thought about dynamically updating the frame rate CAPS of my plugin and
let an upstream videorate plugin handle the frame rate changes. However, I
feel like this would make the adjustments happen too late: if the first
frame takes 1 sec to process, I'll already have 29 frames queued up to catch
up before I get a filtered input.

>From the docs, I feel like supporting pull mode would be perfect for my use
case. This way, I could easily come up with 2 different pipelines: one that
would handle each frame but fall behind quickly, and one that would drop
unhandled frames and pull the latest frame every time we have processing
power available.
However, I couldn't come up with a pipeline that actually does this. I
thought putting a "queue max-size-buffers=1 leaky=downstream" upstream would
do the trick, however this guy doesn't support pull mode according to my

I also thought about putting an upstream valve and update its "drop"
property dynamically, however I feel like this is bad architecture because
my plugin would need to be aware of its upstream plugin, by specifically
looking for this valve. Actually, I don't even know if this is even possible
since I haven't tested it yet, but it just feels wrong.

Has anyone ever done something like this? I'd love to have some help about
the architecture I should use for this particular use case.

Sent from:

More information about the gstreamer-devel mailing list