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
cameras:
*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
issued:
*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,
multiview-mode=(string)mono,
multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono,
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
reasons.
--
Sent from:
http://gstreamer-devel.966125.n4.nabble.com/_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Locked
