GNOME Bugzilla – Bug 766310
gstbasetransform: Error negotiating new framerate
Last modified: 2016-11-11 17:20:01 UTC
Created attachment 327683 [details] Test program Hi, I have the following pipeline (I really have a more complicated pipeline but I have reduced the complexity trying to understand the problem): videotestsrc!videorate!videoconvert!capsfilter!videorate!videoconvert!capsfilter!autovideosink I have detected that if I change dynamically the framerate in the second capsfilter I get a non negotiated error in the videoconvert. I have the following trace: 0:00:07.816591895 32762 0x1a0c940 WARN basetransform gstbasetransform.c:1414:gst_base_transform_setcaps:<videoconvert1> transform could not transform video/x-raw, width=(int)320, height=(int)240, framerate=(fraction)16/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, format=(string)YUY2 in anything we support This problem breaks the pipeline if you use another source like the uridecodebin. I have attached a test program to reproduce the error. That program creates the shown pipeline and it changes the caps of the second capsfilter each second. If you execute the program with GST_DEBUG=2 you could see the error traces. Have you seen this error before? Am I doing something wrong? Thanks for your time. Regards.
I didn't look closely but this might be because upstream renegotiation is not instantanous and you might still get buffers in the old format. Try the caps-change-mode property set to "delayed" in the capsfilter(s).
Hi Sebastian, Thanks for your answer. That property fixes the test but I have tested it in my whole application and it still doesn't work. I will try to understand the difference between the application and the test. Thanks for you time. Regards.
Ok, let us know if you have a new testcase :)
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!