[Resent without HTML content] > On 6 Sep 2016, at 15:28, Andrey Utkin <andrey_utkin@xxxxxxxxxxxx> wrote: > > On Tue, Sep 06, 2016 at 01:51:51PM +0300, Oliver Collyer wrote: >> So today I installed Ubuntu 16.04 on another PC (this one a high spec machine with a Rampage V Extreme motherboard) and I reproduced exactly the same errors and trace. >> >> Rebooting the same PC back into Windows 10 and using the same USB 3.0 port, I had no problems capturing using FFmpeg via DirectShow. I could start and stop the capture repeatedly without any warnings or errors appearing in FFmpeg (built from the same source). >> >> If the hardware is misbehaving, on both these capture devices, then DS must be handling it better than V4L2. Or there is simply an obscure bug in V4L2 which only manifests itself with certain devices. >> >> Would providing ssh access to the machine be of interest to anyone who wants to debug this? > > I am curious to tinker with this, just not sure about free time for it. > Please go through the following instruction, and then we'll see if ssh > is going to help to debug this. > > Also I think it is worth to CC actual manufacturers. There are addresses > for technical support of both devices in public on maker websites. > Please CC them when replying with new logs, to let them catch up. > > So, I am still not certain what confuses the device, i.e. where the > faulty usage pattern comes from: ffmpeg or driver. So I'd like you to > check the difference with various userspace applications which involve > streaming from device. > > For each of your two devices, alone (not two at same time), do this: > > For each command from this list: > "v4l2-compliance -s -d /dev/video0", > "ffmpeg -f v4l2 -i /dev/video0 -vcodec rawvideo -f null -y /dev/null", > "<what you referred to as 'capture API example'>" > (feel free to add more, maybe mplayer invocation or such) > > dmesg -C > plug in the device > modprobe uvcvideo module > run the command twice or more in row > save uncut commands output (with command lines) to separate file > rmmod uvcvideo > unplug the device > save "dmesg" output to separate file > > > Done. > > I guess this test makes sense, or am I missing something you've already > told us? > > If you go making a script for this, make sure to notice if rmmod fails > for any reason, etc. Hi Andrey Thanks for your response and suggestions for tests. Attached is an archive containing the log files you requested. I did modify the test regime slightly as follows: dmesg -C plug in the device modprobe -v uvcvideo run the command once (1) modprobe -v -r uvcvideo modprobe -v uvcvideo run the command again (2) run the command again (3) save uncut commands output (with command lines) to separate file modprobe -v -r uvcvideo unplug the device save “dmesg” output to separate file The reason for the additional unload/load of the uvcvideo module after running command (1) is because I was finding that this command was producing the error straightaway with the Magewell device and it took another unload/reload sequence to produce the next error free command (2). The next command (3) then brings back the error. However, this did vary with the inogeni device - in this case, the (1) and (2) didn’t produce the error, but (3) did. Except in the case of the ffmpeg test which followed the same pattern as the Magewell device. The other difference between the Magewell and Inogeni tests was in the case of the Inogeni it seems that even when the error didn’t occur, ffmpeg was still producing other warnings and errors relating to the capture that the Magewell didn’t produce, which appear to relate to timestamps. The example capture comes from this page on the V4L2 wiki: https://linuxtv.org/downloads/v4l-dvb-apis/capture-example.html …with the addition of these lines from line 125: if (buf.flags & V4L2_BUF_FLAG_ERROR ) { fprintf(stderr, "corrupt buffer\n"); } The capture example doesn’t do anything with the output so even if it was corrupt it wouldn’t make any difference, thus I’ve added some trace to flag the error. For reference/your own testing I’ve attached it to this mail too. In summary: - both devices produce the Error -71 error leading to the V4L2_BUF_FLAG_ERROR error under similar circumstances, but unloading/reloading the uvcvideo module gets rid of it for one time only. - the error state occurs in both the capture example and FFmpeg. - the compliance outputs produces some warnings and errors for both devices, but I don’t know their significance. Regards Oliver PS I’ve copied in support from Magewell and Inogeni - please refer to the linux-media archives for the full history of this discussion concerning capture issues in FFmpeg with your devices, when using V4L2. http://www.spinics.net/lists/linux-media/msg105073.html
<<attachment: v4l2_capture_logs.zip>>
Attachment:
capture_example.c
Description: Binary data
