Slow plugin skipping frames when needed

[MathieuP]

Latest news is, I decided to create my own plugin to achieve something
similar to what queue2 can do when using a file or a ring-buffer: work in
Push mode in its sink pad, and in Pull mode on its src pad.

My issue is that my entire pipeline works well in Push mode, but when I use
Pull mode, the upstream guy doesn't Push anything. I tried replacing my
plugin with queue2, and the upstream Push works perfectly fine, so I'd
assume the problem is with my "custom queue" plugin.

Looking at the source code, I can't see any additional step queue2 does
during query/activatemode phases. I feel like it might be a threading issue,
where my Pull plugin does start its own thread as expected via
gst_pad_start_task, but this somehow disables the default behaviour of the
upstream plugins looping on a thread provided by the gstreamer framework
itself.

Has anyone ever encountered something like this?


MathieuP wrote
> Hi,
> 
> 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
> tests.
> 
> 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: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list

> gstreamer-devel at .freedesktop

> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel





--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/