videorate strange behavior

dorin at
Wed Aug 12 09:39:11 UTC 2020

I have a rtsp video decoding chain with videorate element because I want to
limit the fps to a fixed value.

*gst-launch-1.0 uridecodebin uri="rtsp://..." ! videorate drop-only=1
max-rate=2 ! glimagesink*

This works as expected in most cases, but for some old cameras the fps is
not limited, instead videorate lets all frames pass through (around 25 fps).
It seems like for these old cameras, the decoding chain does not correctly
detect the caps.

If I add a caps filter after videorate, it also works as expected for most
*gst-launch-1.0 uridecodebin uri="rtsp://..." ! videorate drop-only=1
max-rate=2 ! video/x-raw,framerate=2/1 ! glimagesink*

But for the old cameras, the buffers are dropped and the following warnings

*0:00:07.816273650  2344 0x7f26800074a0 WARN           basetransform
gstbasetransform.c:1355:gst_base_transform_setcaps:<videorate0> transform
could not transform video/x-raw, format=(string)I420, width=(int)704,
height=(int)480, interlace-mode=(string)progressive,
pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)mpeg2,
colorimetry=(string)bt601, framerate=(fraction)0/1 in anything we support*

I thought videorate works on the actual buffer timestamps and does not care
about sample caps (which in this case are falsely reported as 0/1).

Is there a workaround for videorate to achieve what I want in a reliable and
robust way? I am using python-gi so it's also possible to attach buffer
probes on pads and manipulate stuff but it's best avoided for performance

Sent from:

More information about the gstreamer-devel mailing list