GNOME Bugzilla – Bug 349107
gst.BaseSrc can't negotiate with ffmpegcolorspace
Last modified: 2006-09-22 12:11:28 UTC
Please describe the problem: If you write a home made src element extending gst.BaseSrc, it will not be able to negotiate properly with a ffmpegcolorspace element even if the buffer pushed from the src element clearly has caps that that ffmpegcolorspace can handle. Steps to reproduce: Download the attached .tar.gz, extract both files to the same directory. Make sure there's a playbin-playable video file called /tmp/movie.avi and run: "GST_DEBUG=2 python playbin_test2.py". On the GUI that is displayed, click the "snapshot" button. Actual results: Lots of debug printout, ending with: WARN (0x86bb3a0 - 0:00:06.888466000) basetransform(19244) gstbasetransform.c(1395):gst_base_transform_handle_buffer:<csp1> error: not negotiated WARN (0x86bb3a0 - 0:00:06.888592000) basetransform(19244) gstbasetransform.c(1395):gst_base_transform_handle_buffer:<csp1> error: not negotiated WARN (0x86bb3a0 - 0:00:06.888758000) basesrc(19244) gstbasesrc.c(1510):gst_base_src_loop:<injector_src> error: Internal data flow error. WARN (0x86bb3a0 - 0:00:06.888905000) basesrc(19244) gstbasesrc.c(1510):gst_base_src_loop:<injector_src> error: streaming task paused, reason not-negotiated Expected results: I excpected to get a frame encoded as a .png file in /tmp/snapshot.png Does this happen every time? Yes Other information: It is not certain that this is a python binding bug, but wtay in the irc channel suggested that.
Created attachment 69838 [details] Debug log
In order to figure out exactly the source of the problem, could you attach the python sourcecode you're using ?
The python sourcecode is already available in the attachement called "Debug log", the file is called playbin_test2.py. (The attachement is named "Debug log" which is not really a good description of it...)
Created attachment 69971 [details] The REAL debug log Added the actual GST_DEBUG=5 debug log from running this program. The attachement called "Debug log" is actuallay the program itself. I know, it's confusing, I'm sorry.
I've done some research. Look at line 97291 in debug.log (attachement "The REAL debug log"). It says: GST_CAPS( 8036) gstpad.c(2464):gst_pad_get_negotiated_caps: negotiated caps (NULL) Here, something has gone wrong, I think. The caps in question should not be NULL here, they should be something like video/x-raw-yuv, format=(fourcc)I420, width=(int)720, height=(int)576, framerate=(fraction)625/52, pixel-aspect-ratio=(fraction)1/1, but that depends on the avi file you're testing with, of course. Now look at line 35 in the python code (playbin_test2.py in the attachement confusingly named "Debug log" below), where I call alloc_buffer. You see there that I DO send in self.mybuffer.caps, which here is definately NOT null. So, for some reason, it seems that when using gst.Pad.alloc_buffer (or, for that matter, gst.Pad.alloc_buffer_and_set_caps) the caps does not actually get set properly. This makes the subsequent negotiation fail. I don't know why the caps does not get set properly. But I think that the problem lies in how the binding for gst.Pad.alloc_buffer (and gst.Pad.alloc_buffer_and_set_caps works).
works fine here with cvs of everything... Could you give it a try ?
I can. At the same time, you think that maybe you could try with 0.10.4 that the bug is reported for?
I fix bugs in cvs versions. There's nothing that can be done for released versions.
Closing issue. Re-open if it doesn't work with cvs version (or 0.10.6 when it's out).
I just tried the cvs version; you are correct. This is fixed. (Thanks!)