After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 349107 - gst.BaseSrc can't negotiate with ffmpegcolorspace
gst.BaseSrc can't negotiate with ffmpegcolorspace
Status: VERIFIED FIXED
Product: GStreamer
Classification: Platform
Component: gst-python
0.10.4
Other All
: Normal normal
: 0.10.6
Assigned To: GStreamer Maintainers
Johan (not receiving bugmail) Dahlin
Depends on:
Blocks:
 
 
Reported: 2006-07-28 16:53 UTC by Fredrik Persson
Modified: 2006-09-22 12:11 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Debug log (1.67 KB, application/x-gzip)
2006-07-28 17:09 UTC, Christian Fredrik Kalager Schaller
Details
The REAL debug log (738.86 KB, application/x-bzip)
2006-07-31 14:08 UTC, Fredrik Persson
Details

Description Fredrik Persson 2006-07-28 16:53:22 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.
Comment 1 Christian Fredrik Kalager Schaller 2006-07-28 17:09:12 UTC
Created attachment 69838 [details]
Debug log
Comment 2 Edward Hervey 2006-07-30 16:59:26 UTC
In order to figure out exactly the source of the problem, could you attach the python sourcecode you're using ?
Comment 3 Fredrik Persson 2006-07-30 18:19:55 UTC
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...)
Comment 4 Fredrik Persson 2006-07-31 14:08:46 UTC
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.
Comment 5 Fredrik Persson 2006-08-05 23:18:46 UTC
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).
Comment 6 Edward Hervey 2006-08-23 08:53:56 UTC
works fine here with cvs of everything... Could you give it a try ?
Comment 7 Fredrik Persson 2006-08-23 09:25:47 UTC
I can. At the same time, you think that maybe you could try with 0.10.4 that the bug is reported for?
Comment 8 Edward Hervey 2006-08-23 09:28:12 UTC
I fix bugs in cvs versions. There's nothing that can be done for released versions.
Comment 9 Edward Hervey 2006-09-22 11:55:57 UTC
Closing issue. Re-open if it doesn't work with cvs version (or 0.10.6 when it's out).
Comment 10 Fredrik Persson 2006-09-22 12:11:28 UTC
I just tried the cvs version; you are correct. This is fixed. (Thanks!)