GNOME Bugzilla – Bug 449483
[v4l2src] doesn't work anymore with BT878
Last modified: 2009-01-09 22:57:41 UTC
I use both Osprey 440 and Osprey 230 which contain BT878 chips. Pipelines which used to work fine don't work anymore after I've upgraded my Debian box to plugins-good-0.10.6 This one works fine : $ gst-launch v4lsrc device=/dev/video3 ! video/x-raw-yuv,width=720,height=576 \ ! queue \ ! ffmpegcolorspace \ ! queue \ ! ximagesink But if I replace "v4lsrc" with "v4l2src" above, it doesn't work anymore. See the attached trace file I'll upload in a few minutes with GST_DEBUG=4, as asked by Wingo on IRC.
Created attachment 90338 [details] Gzipped log file with GST_DEBUG=4 Gzipped trace produced with v4l2src instead of v4lsrc in the above pipeline.
Thanks. It looks like that for the linux < 2.6.19 case in v4l2src_calls.c:gst_v4l2src_probe_caps_for_format, that we need to include the code from v4l2src_calls.c:gst_v4l2src_get_size_limits. Also it seems that for the < 2.6.19 case we need to do something smarter with framerates; it's likely that supporting webcams with older kernels isn't worth it, but that we have the necessary ioctls to support tv cards.
Jerome: What framerate does your v4lsrc negotiate to? What is the expected framerate?
I can't check with ximagesink at the moment because I'm currently at home, but through ssh I've tried the same pipeline with v4lsrc and fakesink, and what was negotiated is : basetransform gstbasetransform.c:787:gst_base_transform_setcaps:<ffmpegcsp0> Input caps were video/x-raw-yuv, format=(fourcc)I420, width=(int)720, height=(int)576, framerate=(fraction)25/1, and got final caps video/x-raw-yuv, format=(fourcc)I420, width=(int)720, height=(int)576, framerate=(fraction)25/1 So I suppose the default framerate when not specified is 25/1. FYI these chips can do up to 924x576 @ 30fps, although I've never tried 30fps, and I remember having messages about incorrect buffer size problems when trying 924x576 with the older release of plugins-good. Personally I only need to use them at 176x144 @ 5fps currently, but I can do any testing you need, just ask.
Does the patch in bug #450190 help by any chance?
Unfortunately I'm not sure to be able to test a patch before the second half of July due to very high time constraints wrt availability of our hardware.
Any chance you could re-try with current CVS of v4l2src and create a new debug log if it still doesn't work?
> Thanks. It looks like that for the linux < 2.6.19 case in > v4l2src_calls.c:gst_v4l2src_probe_caps_for_format, that we need to include the > code from v4l2src_calls.c:gst_v4l2src_get_size_limits. I think this is fixed in CVS now, which leaves this as far as I understand: > Also it seems that for the < 2.6.19 case we need to do something smarter with > framerates; it's likely that supporting webcams with older kernels isn't worth > it, but that we have the necessary ioctls to support tv cards.
No feedback - closing as per last comment.