As this is specific to your driver, please tells us more about your driver. If you have no idea, you can simply re-run this and *attach* a trace from:

GST_DEBUG="v4l2*:7" gst-launch-1.0 v4l2src ! checksumsink 3> gst.log

And yes, v4l2 elements now support manual use of userptr, dmabuf and dmabuf-import. Note that this only work if you build without libv4l2 for now and requires videobuf2 based driver.

Created attachment 290207 [details]
Debug Logfile

Hello Nicolas Dufresne,

Source code is built without libv4l2 and 
We are using Linux 3.10.0-123.el7.x86_64 kernel version which has videobuf2. But I am not sure whether my device driver supports videobuf2.

I have attached logs of below pipeline.
GST_DEBUG="v4l2*:7" gst-launch-1.0 v4l2src ! checksumsink 2> gst.log  


Thank you..
~ Sudhir

Ok, first spot where things go wrong is:

gstv4l2object.c:1660:gst_v4l2_object_probe_caps_for_format_and_size:<v4l2src0>
D  get frame interval for 720x576, YUYV
W  Unknown frame interval type at YUYV@720x576: 0
D  done iterating discrete frame sizes
D  No results for pixelformat YUYV enumerating frame sizes, trying fallback

Sadly there is no trace for v4l2_frmivalenum::type, so I can't tell what value the driver may have choose, but it's clear that it's invalid.

This has the consequence that we fall back to some ancient code, that rely on TRY_FMT, but this driver does not seem to validate TRY_FORMAT. We endup with resolution 320x288 instead of 720x576, against neither S_FMT or REQBUF fails (this driver implementation is really dummy it seems), and then it fails when we try to capture the first buffer.

I have some homework for you (since I can't try it myself ;-P):

1. Try and fix the format, tell me if it works, give me the trace if it doesn.
  gst-launch-1.0 v4l2src | video/x-raw,width=720,height=576 | checksumsink

2. Provide me a trace on 1.2 the shows what happen when it works

By the way, I still can't figure-out what driver is this. If you have any information about which driver, is it out of tree or in tree, that would help too. The driver names itself 'LINUXV4L2' and set the card name as 'SA7160:RAW 00.00', googling that does not help.

Created attachment 290307 [details]
Log Files

Thank you very much for the reply.

I have attached log files of below given pipeline for Gstreamer 1.2.2 and 1.4.4.

GST_DEBUG="v4l2*:7" gst-launch-1.0 v4l2src ! video/x-raw,width=720,height=576 ! checksumsink

File info:
v4l2src_1_2_2.txt > gstreamer 1.2.2 
v4l2src_1_4_4.txt > gstreamer 1.4.4 

My understanding after going through the log files(I may be wrong), In 1.2.2 buffer type is configured as MMAP and it is successful, but in 1.4.4 GST_V4L2_ALLOCATOR_PROBE fails to probe allocator type MMAP and throws the following warning

v4l2allocator gstv4l2allocator.c:651:gst_v4l2_allocator_new:<v4l2src0:pool:src:allocator> Could not probe supported memory type, assuming MMAP is supported, this is expected for older drivers not  yet ported to videobuf2 framework.

(Same warning is marked as error in 1.4.1).

 >  1. Try and fix the format, tell me if it works, give me the trace if it doesn't.
  Could you please elaborate on this. What you mean by format?? 
  Attached log files are without any source code modification in 1.4.4.
 
 About the device driver.
 Device driver supports videobuf2. I am collecting additional data on this.
 
 Thanks,
 ~ Sudhir

(In reply to comment #7)
> 
> My understanding after going through the log files(I may be wrong), In 1.2.2
> buffer type is configured as MMAP and it is successful, but in 1.4.4
> GST_V4L2_ALLOCATOR_PROBE fails to probe allocator type MMAP and throws the
> following warning
> 
> v4l2allocator
> gstv4l2allocator.c:651:gst_v4l2_allocator_new:<v4l2src0:pool:src:allocator>
> Could not probe supported memory type, assuming MMAP is supported, this is
> expected for older drivers not  yet ported to videobuf2 framework.

We changed this into a warning to try and support older driver that does not comply with the spec. Basically if a driver says it's streaming, then we assume MMAP is supported. This partially fixed support for BTTV. About that, could you run v4l2-compliance against your driver, that should tell us a bit more about what it does not do right. You'll find this test in:

http://git.linuxtv.org/cgit.cgi/v4l-utils.git/

> 
>  >  1. Try and fix the format, tell me if it works, give me the trace if it
> doesn't.
>   Could you please elaborate on this. What you mean by format?? 
>   Attached log files are without any source code modification in 1.4.4.

That means try:
gst-launch-1.0 v4l2src | video/x-raw,width=720,height=576 | checksumsink

And tell me if it works or not. Basically, what the driver seems to do wrong is that it does implement frame size enumeration, but not the frame period. We could hack around by looking at the chosen video standard, but it's a totally unreliable method, since implementing video standard is optional.


> 
>  About the device driver.
>  Device driver supports videobuf2. I am collecting additional data on this.

Good, normally when we hit such a broken driver, I normally look at the driver code to figure-out, but this one is of unknown source to me.

v4l2-compliance report of device driver.

Driver Info:
        Driver name   : LINUXV4L2
        Card type     : SA7160:RAW 00.00
        Bus info      : PCI Bus 0000:06
        Driver version: 1.0.0
        Capabilities  : 0x04021001
                Video Capture
                Video Capture Multiplanar
                Audio
                Streaming

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
                fail: v4l2-compliance.cpp(306): missing bus_info prefix ('PCI Bus 0000:06')
        test VIDIOC_QUERYCAP: FAIL

Allow for multiple opens:
        test second video open: OK
                fail: v4l2-compliance.cpp(306): missing bus_info prefix ('PCI Bus 0000:06')
        test VIDIOC_QUERYCAP: FAIL
                fail: v4l2-compliance.cpp(365): doioctl(node, VIDIOC_G_PRIORITY, &prio)
        test VIDIOC_G/S_PRIORITY: FAIL

Debug ioctls:
        test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
        test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
        test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
        test VIDIOC_ENUMAUDIO: OK
                fail: v4l2-test-input-output.cpp(380): invalid std
                fail: v4l2-test-input-output.cpp(437): invalid attributes for input 0
        test VIDIOC_G/S/ENUMINPUT: FAIL
                fail: v4l2-test-input-output.cpp(539): audio inputs found but no video inputs?!
        test VIDIOC_G/S_AUDIO: FAIL
        Inputs: 0 Audio Inputs: 2 Tuners: 0

Output ioctls:
        test VIDIOC_G/S_MODULATOR: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_ENUMAUDOUT: OK (Not Supported)
        test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDOUT: OK (Not Supported)
        Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
        test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
        test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
        test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
        test VIDIOC_G/S_EDID: OK (Not Supported)

        Control ioctls:
                test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
                test VIDIOC_QUERYCTRL: OK
                test VIDIOC_G/S_CTRL: OK
                fail: v4l2-test-controls.cpp(575): g_ext_ctrls worked even when no controls are present
                test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
                test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
                test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
                Standard Controls: 0 Private Controls: 0

        Format ioctls:
                fail: v4l2-test-formats.cpp(157): invalid width/height for discrete framesize
                test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: FAIL
                test VIDIOC_G/S_PARM: OK
                test VIDIOC_G_FBUF: OK (Not Supported)
                fail: v4l2-test-formats.cpp(411): !pix.width || !pix.height
                test VIDIOC_G_FMT: FAIL
                test VIDIOC_TRY_FMT: OK (Not Supported)
                test VIDIOC_S_FMT: OK (Not Supported)
                test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)

        Codec ioctls:
                fail: v4l2-test-codecs.cpp(47): ret == ENOTTY
                test VIDIOC_(TRY_)ENCODER_CMD: FAIL
                test VIDIOC_G_ENC_INDEX: OK (Not Supported)
                test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

        Buffer ioctls:
                test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
                test VIDIOC_EXPBUF: OK (Not Supported)


Total: 39, Succeeded: 30, Failed: 9, Warnings: 0


Also please go trough gstreamer 1.2.2 and 1.4.4 that might give some hint..
I had attached both logs in previous comment..

~ Sudhir

Outch, that is a lot failure. You where lucky it worked before I think. Thanks for the report, it gives a better idea of the state of this driver. I'll later have a look at the log, but can't promise a fix will really be possible.

(In reply to comment #10)

Yes there are many failed and Not supported cases.

Interestingly capture is working with VLC. Currently I am looking into VLC logs to check whether any reliance is added by it to make it work.
 
~ Sudhir

I've checked the two traces and differences are:

a) 1.2 allocates 4 buffers while 1.4 allocates 2
b) There is possible difference in buffer.bytesused/length between 1.2 and 1.4.

You can check if a) is the issue by modifying GST_V4L2_MIN_BUFFERS constant to be 4 (in gst-plugins-good/sys/v4l2/gstv4l2object.h).

For b), you'd have to instrument the code a little more, so we know the values in set in the v4l2_buffer, maybe you drivers requires a specific field to be set, and that it was omitted in 1.4.

Providing your custom driver source code would also be key to get some more help here.

(In reply to comment #12)
> I've checked the two traces and differences are:
> 
> a) 1.2 allocates 4 buffers while 1.4 allocates 2
> b) There is possible difference in buffer.bytesused/length between 1.2 and 1.4.
> 
> You can check if a) is the issue by modifying GST_V4L2_MIN_BUFFERS constant to
> be 4 (in gst-plugins-good/sys/v4l2/gstv4l2object.h).
> 

I modified GST_V4L2_MIN_BUFFERS to 4. I dont see any difference in the behaviour.

> For b), you'd have to instrument the code a little more, so we know the values
> in set in the v4l2_buffer, maybe you drivers requires a specific field to be
> set, and that it was omitted in 1.4.
> 

I am modifying the code and will update the results.


> Providing your custom driver source code would also be key to get some more
> help here.

I do not have driver source code. We are using third party capture device and device driver.

(In reply to comment #13)
> > Providing your custom driver source code would also be key to get some more
> > help here.
> 
> I do not have driver source code. We are using third party capture device and
> device driver.

Note, it's a pleasure helping in finding the root cause, as I like to understand what change made the break. Though, you could already point your third party provider toward the compliance test.

(In reply to comment #14)
> (In reply to comment #13)
> > > Providing your custom driver source code would also be key to get some more
> > > help here.
> > 
> > I do not have driver source code. We are using third party capture device and
> > device driver.
> 
> Note, it's a pleasure helping in finding the root cause, as I like to
> understand what change made the break. Though, you could already point your
> third party provider toward the compliance test.



Sorry for the late reply.
I have sent compliance report to driver developers. I will get back once they give patch driver.

Thank you very much Nicolas for your help.

~ Sudhir

Hi all,

After commenting piece of code (gstv4l2bufferpool.c:981) capture is working.  
  
  if (gst_poll_fd_has_error (pool->poll, &pool->pollfd))
      goto select_error;

Please can anybody explain me what gst_poll_fd_has_error function checking for?? Any specific FD flags??

Is it driver issue ??

~ Sudhir

It's documented here:
http://linuxtv.org/downloads/v4l-dvb-apis/func-poll.html

It checks if POLLERR flag is set on the poll structure. If it's the case, it means there was a fatal error reported by the driver. Normal procedure is to stop any operation and start again. Your driver should not set this flag unless it's it's in trouble and can't recover.

Note that as this isn't a support forum, I would like you to consider providing the required information, which is in this case more information about the driver (driver must be GPL if it's running in the kernel). Otherwise, I may have to simply close this bug.

Please re-open if you can provide appropriate information.

POLLERR is not handled properly in device driver. With that correction now we are able to capture.

Thank you very much for the information and link provided.

Ah, thanks for letting us know.