Hi all I’ve been trying to workaround some issues in FFmpeg relating to the V4L2_BUF_FLAG_ERROR flag being passed from V4L2. In particular this bug here: https://trac.ffmpeg.org/ticket/4988 The long and short of it is that this error comes through several times at the start of a capture and FFmpeg struggles to handle it properly, despite previous attempts at fixing (such as this one https://trac.ffmpeg.org/ticket/4030) I’ve also reproduced this outside of FFmpeg using the capture example that is part of the V4L2 API: https://www.linuxtv.org/downloads/v4l-dvb-apis/capture-example.html Further, I have the following two devices in my possession and both produce the error, so it doesn’t seem to be related to the specific hardware, unless they are somehow making the same mistake: Magewell XI100DUSBHDMI Inogeni DVI2USB3 Significantly, the error does not occur the first time after the USB device is connected (or the machine rebooted or the uvcvideo kernel module reloaded), however it appears 100% of the time thereafter. I downloaded and built the latest media_build and re-loaded the newly built uvcvideo module but I still get the same behaviour. The issue can be worked around by using modprobe to unload and reload uvcvideo before each capture. Here is some dmesg output: These lines appear when the uvcvideo modules is removed and then added again: [43909.871585] usbcore: deregistering interface driver uvcvideo [43910.117724] media: Linux media interface: v0.10 [43910.120736] Linux video capture interface: v2.00 [43910.120738] WARNING: You are using an experimental version of the media stack. As the driver is backported to an older kernel, it doesn't offer enough quality for its usage in production. Use it with care. Latest git patches (needed if you report a bug to linux-media@xxxxxxxxxxxxxxx): 23ea23617ba96f7969aa5c175ebaad9557612171 Merge branch 'docs-next' of /git/mchehab/experimental into docs-next fb6609280db902bd5d34445fba1c926e95e63914 [media] dvb_frontend: Use memdup_user() rather than duplicating its implementation 8eb14e8084b0f39dbf23dcd0c263fc2fac862048 [media] vb2: Fix vb2_core_dqbuf() kernel-doc [43910.122896] uvcvideo: Found UVC 1.00 device XI100DUSB-HDMI (2935:0001) [43910.123874] uvcvideo 2-4:1.0: Entity type for entity Processing 2 was not initialized! [43910.123877] uvcvideo 2-4:1.0: Entity type for entity Camera 1 was not initialized! [43910.123952] input: XI100DUSB-HDMI as /devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4:1.0/input/input27 [43910.124016] usbcore: registered new interface driver uvcvideo [43910.124018] USB Video Class driver (1.1.1) I then run a capture using FFmpeg or the capture example in the V4L2 API and it works fine, so there is no more trace. However if I run the same capture/test subsequently I always get these two lines: [43950.910465] uvcvideo: Non-zero status (-71) in video completion handler. [43950.910483] videobuf2-v4l2.c: setting V4L2_BUF_FLAG_ERROR The second line is trace I added myself to show when it sets the buffer error flag. As you can see, first of all there is an error (-71) in the video completion handler, and then shortly afterwards the buffer error flag gets set. It would appear that when the first capture ends something isn’t being cleaned-up properly, leading to the error state for subsequent captures and the knock-on effects to FFmpeg or anything using V4L2. These are two of the most popular USB3 capture devices out there so it would be great to get to the bottom of this. I know apps are expected to workaround V4L2_BUF_FLAG_ERROR but in the case of FFmpeg it’s a little problematic because even if we just discard the buffer it still ends up throwing the timestamps of the input out of whack with the output leading to tons of FFmpeg warnings. Since this happens 100% of the time from the second capture onwards for these devices, and is clearly resolved by a module reload it seems that the best approach would be to fix the underlying cause if possible. If I can provide any more info please let me know. I am happy to test/make any suggested fixes or even provide ssh access to the machine if necessary. Regards Oliver oliver@NUC-1:~$ uname -a Linux NUC-1 4.4.0-36-generic #55-Ubuntu SMP Thu Aug 11 18:01:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux oliver@NUC-1:~/media_build/linux$ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 94 Model name: Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz Stepping: 3 CPU MHz: 1501.500 CPU max MHz: 3500,0000 CPU min MHz: 800,0000 BogoMIPS: 5183.87 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 6144K NUMA node0 CPU(s): 0-7 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp oliver@NUC-1:~/media_build/linux$ lsusb Bus 002 Device 002: ID 2935:0001 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 8087:0a2b Intel Corp. Bus 001 Device 005: ID 1c4f:0002 SiGma Micro Keyboard TRACER Gamma Ivory Bus 001 Device 004: ID 05ac:921c Apple, Inc. A1082 [Cinema HD Display 23"] Bus 001 Device 006: ID 09da:000a A4Tech Co., Ltd. Optical Mouse Opto 510D / OP-620D Bus 001 Device 002: ID 05ac:911c Apple, Inc. Hub in A1082 [Cinema HD Display 23"] Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub-- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
