Video capture from stk1160 device fails #620
Comments
|
When you say you get a frame before it stops, is the frame garbled or readable? |
|
The file captured from avconv command above (/tmp/KK.flv) is empty. I do not get to see how the (short) frame looks like. |
|
I gave it another try $ v4l2-ctl --stream-mmap=8 --stream-count=2 --stream-to=KK.raw
$ avconv -f rawvideo -pix_fmt uyvy422 -s 720x576 -i KK.raw KK-%2d.jpg
$ ls KK*
KK-01.jpg
KK.rawIf I only order count 1 pictures, no jpeg will be produced. The picture is a mess, although it shows great promise ;) The camera (analog PAL b/w) was lying upside down. Part of the image is perfect: If avconv does de-interlace, would that explain why a single frame will produce no image? I suppose scanning starts at top left and proceeds to bottom left: somewhere some pixels in the even line are missing; see yourselves below: |
|
Can you post a |
|
|
If you add the parameter |
|
No, the picture now is chopped in rectangular regions too and parts doubled. (The green bar I am used to, this happens with analogue equipment.) Several tries all the same. See below: With the other one and Gimp filter deinterlace I could get a good picture, but maybe that was only luck? |
|
With the FIQ accelerating the transactions (mask |= 0x4) it seems the transfer is far more reliable. I think the driver (or userspace program) may not be expecting corrupt frames and ends up throwing them away. Does guvcview (gui-based webcam/v4l viewer) work with it? |
|
The graphical viewer fails to start. I rather not strace it. Beware that this is from an xrdp session (so puts extra stress on the network and therefore usb): Don't you think, that the v4l2-ctl command captures raw bits as they come from the device, that the stream has no frame marks, and that the userspace avconv program just splits at byte counts (w×h×d), as far as I understand -- which would imply, that the doubling of area above would be the next frame(s). Curiously, dmesg is littered with [Buffer error (overrun)] entries, not /underrun/. |
|
PS: There must be frame markers somewhere at least in driver space, how else would avconv capture know how many bytes to expect in a frame; the v4l2-ctl seems not to care though. Such markers may even be present in the stream-dump: the avconv file conversion reports errors, though gives no specifics. |
|
Will the Model B+ make a difference in this regard or is this still handicapped on high throughput? |
|
The same OTG hardware is present on the Model B+ (it's the same SOC), so no difference. I purchased a "random" easycap device a couple of weeks ago and it appears to be a usbtv007 clone. I will see if I can replicate the issue. |
|
I have a similar capture device, also experiencing buffer overruns. [ 33.223976] stk1160: registers to NTSC like standard [ 33.384628] stk1160: queue_setup: buffer count 8, each 691200 bytes [ 33.413614] stk1160: setting alternate 5 [ 33.413645] stk1160: minimum isoc packet size: 3072 (alt=5) [ 33.413656] stk1160: setting alt 5 with wMaxPacketSize=3072 [ 33.431748] stk1160: allocating urbs... [ 33.438841] stk1160: cannot alloc 196608 bytes for tx[15] buffer [ 33.438865] stk1160: 14 urbs allocated. Trying to continue... [ 33.471129] stk1160: streaming started [ 33.543973] URB packet 0, status -63 [Buffer error (overrun)]. [ 33.649337] URB packet 12, status -63 [Buffer error (overrun)]. [ 33.649369] URB packet 13, status -63 [Buffer error (overrun)]. I get this when I try to capture video with hyperion-v4l or mplayer root@pi ~ # hyperion-v4l2 -v NTSC
V4L2 width=720 height=480
V4L2 pixel format=UYVY
V4L2 grabber signal threshold set to: {0,0,0}
Connecting to Hyperion: 127.0.0.1:19445
V4L2 grabber started
Frame too small: 680974 != 691200
Frame too small: 690032 != 691200
Frame too small: 671394 != 691200
Frame too small: 690052 != 691200
Already tried several settings of dwc_otg.fiq_fsm_mask dwc_otg.fiq_fsm_mask=0x1 Frame too small: 555638 != 691200 Frame too small: 597436 != 691200 Frame too small: 584364 != 691200 dwc_otg.fiq_fsm_mask=0x3 Frame too small: 595770 != 691200 Frame too small: 594286 != 691200 Frame too small: 563024 != 691200 dwc_otg.fiq_fsm_mask=0x4 Frame too small: 690654 != 691200 Frame too small: 689886 != 691200 Frame too small: 676092 != 691200 dwc_otg.fiq_fsm_mask=0x7 Frame too small: 690020 != 691200 Frame too small: 687680 != 691200 Frame too small: 688510 != 691200 So it seems with 0x4 and 0x7 it's almost there. root@pi ~ # uname -a
Linux pi 3.12.26+ #704 PREEMPT Wed Aug 20 22:35:11 BST 2014 armv6l GNU/Linux
root@pi ~ # lsusb | grep STK1160
Bus 001 Device 005: ID 05e1:0408 Syntek Semiconductor Co., Ltd STK1160 Video Capture Device
root@pi ~ # lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/3p, 480M
|__ Port 1: Dev 3, If 0, Class=vend., Driver=smsc95xx, 480M
|__ Port 2: Dev 4, If 0, Class=HID, Driver=usbhid, 12M
|__ Port 2: Dev 4, If 1, Class=HID, Driver=usbhid, 12M
|__ Port 2: Dev 4, If 2, Class=HID, Driver=usbhid, 12M
|__ Port 3: Dev 5, If 0, Class=vend., Driver=stk1160, 480M
|__ Port 3: Dev 5, If 1, Class=audio, Driver=snd-usb-audio, 480M
|__ Port 3: Dev 5, If 2, Class=audio, Driver=snd-usb-audio, 480M
Any recommendations on what else to try? Thanks! |
|
I'm certainly no expert on this topic but I've spent a couple of days trying to figure this out and wasn't able to get anywhere. I have the STK1160 and the best picture I can get is stable about 50% of the time, and flickers horribly and looks like the images above the rest of the time (seem to coincide with the "Frame too small" messages). There are some rumors that it's related to the USB bus on the Pi - great info here, http://easycap.blogspot.co.uk/2013/03/raspberry-pi-and-easycap-devices.html. I have ordered another capture card, the Fushicai as discussed here... http://raspberry-at-home.com/video-grabber-for-raspberry-pi/. |
|
@knowncolor ,have you had any luck with this issue? I've gotten an STK1160 to capture video on the 3.6.11+ kernel on a B+. However, I just got a Pi 2 and and my previous code doesn't work. In fact, I can't even replicate the results on this thread here--avconv doesn't even grab a frame. Did the Fushicai card work for you? |
|
@npp1993 I was unable to resolve the flickering. In the end I ordered a new capture device from Lightberry and it works great and with minimal set up. https://lightberry.eu/shop/shop/easycap-video-grabber/ |
|
Sorry for bumping an old issue, but I've hit a similar thing on a totally different project and thought I'd report what has been found there. Feel free to ignore! My device is actually a UVC device, but stk1160 seems to be similar. On URB completion it does a memcpy of the video frame from USB buffer into the V4L2 buffer, and then returns the URB. Our processor was being slightly too slow in doing that memcpy and was running out of URBs to fill, so USB packets got dropped and the frame was reported as being of fewer bytes than expected. The buffers V4L2 presents to userspace do not have Seeing as people here are getting short buffers reported, and the images attached look like there is stale data in buffers, it sounded plausibly relevant. Anyone with one of these devices feel like rebuilding the kernel with STK1160_NUM_BUFS and/or STK1160_MIN_BUFS set higher? |
|
@6by9 Very excited to hear a potentially positive update on this thread! I've not been looking at this issue for some time as I was able to find a different capture device that works, but I spent a lot of time on this in the past and know lots of people were having the same issue. |
|
@tramonex-james Don't count chickens yet. @P33M would probably be the one to know if this is a total red herring. |
|
Same issue here. I just wanted to use my old STK1160 USB-Video grabber card, which worked flawlessly before. When i try to capture data from /dev/video0 i get the following error(s): [video4linux2 @ 0x1faa1e0] The v4l2 frame is 690276 bytes, but 691200 bytes are expected Occasionally the driver works for a couple of seconds/minutes but usually it fails right away. It seems to be independent of the chosen resolution or bitrate. avconv -v verbose -f video4linux2 -i /dev/video0 -s 640x480 -b 5000K -y /home/pi/KK.flv uname -a lsb_release -a dmesg |
|
@hungerburg has this issue been resolved? If yes, then please close this issue. |
|
I still get broken frames with stk1160 on raspbian lite with kernel 4.4. Any ideas on this? Might reducing the frame size solve/reduce the issue? I think it can hardly be hardware related due to the old legacy stk1160 driver worked fine? |
|
@Ruffio Sorry, no success -- Just installed a stock 2016-05-27-raspbian-jessie-lite.img -- which has everything on board -- and got no good capture; Below the same commands as above; on the desktop, the same commands yield fine pictures. On my desktop I extract the frames: That is what it looks like If you close the issue, I do not mind, the Pi may be just too weak for uncompressed video, but there are good alternatives and only few want to use legacy hardware… |
|
The issue touches me with a current Pi 3 and hyperion ambilight. I used a fushicai grabber first, but it gives oversaturated colors and a driver which has no v4l2-ctl commands to adjust anyting. Now i use a stk1160 grabber which has good colors (with chroma=off) but the frame issue leads to blue led flashlights from time to time. I don't know any other grabber hardware for hyperion ambilight, so i think many users are affected by it. I would greatly appreciate any hint or work on this topic! I don't have enough knowledge to undersand if the commits made to the driver in kernel > 4.4 can solve the issue... |
|
I'm also still facing the issue with stk1160 openelec |
|
on a 64-bit kernel (opensuse leap 42.2) on raspi 3 doesn't occurre the tx buffer allocation error. |
|
Thanks for the comment habeIchVergessen. That made me think about how to workaround that limit and I realized that by allocating some contiguous memory at boot kmalloc may draw from that pool and thus the allocation succeeds. |
|
@sassmann u almost saved my life dude!! my stats: running hyperion on the same device
Feb 20 03:50:14 Herbert hyperiond[521]: BLACKBORDER INFO: threshold set to 0 (0) (Yeah i know the service name is another.. this is cause i made 2 another startup scripts to kill the first hyperion startup (cause it caused everytime flickering on the led's) and the second starts it 10 seconds later again. Then it runs smoothly and has no flickering) And after that all, everytime i started to change colors or turned on an effect, the amilight (think the grabber) didn't seem to work anymore after i turned back to it) dmesg gave me similar logs like u: After this log everytime the grabber stopped working. First look if this Setting is on "y" Second add the following in /boot/cmdline.txt Reboot After that the dmesg shows: So we got 32768K cma-reserved! And now the urbs allocated message is gone and i can change colors, effects and anything else, and turn the ambilight back on for watching a movie, as often as i want! :) Im sorry for my bad english.. but its very late in the night, and im very tired, and very excited that we could figured that out together :D |
|
@Vaskyy Indeed, setting cma=32 in cmdline.txt makes the alloc messages disappear; still no good pictures from the cam, this time though the first one is good :) Do you still see these messages in dmesg? |
|
To be clear, I'm still experiencing the buffer errors from time to time, so it's only a partial fix. |
|
yeah, unfortunately i see them too :( So, no one is getting rid of this on stk1160 ? |
|
Closing USB issues as OP has not updated the thread. Further comments by the OP stating that the issue is still present on latest rpi-update kernel will lead to a review. |
|
Still issues with rpi3:
I have replaced cables, tried different psu:s on cams and rpi,different cameras, 2 digizers... Can this be some timing (resources) issue or something? when I take smaller image with multiple frames on it (f.e 240x200) there is no problems. but if image size is as on examples, I start to get interlacing. |
[ Upstream commit 2a762e9 ] There are two types of the lower interface of rmnet that are VND and BRIDGE. Each lower interface can have only one type either VND or BRIDGE. But, there is a case, which uses both lower interface types. Due to this unexpected behavior, lower interface leak occurs. Test commands: ip link add dummy0 type dummy ip link add dummy1 type dummy ip link add rmnet0 link dummy0 type rmnet mux_id 1 ip link set dummy1 master rmnet0 ip link add rmnet1 link dummy1 type rmnet mux_id 2 ip link del rmnet0 The dummy1 was attached as BRIDGE interface of rmnet0. Then, it also was attached as VND interface of rmnet1. This is unexpected behavior and there is no code for handling this case. So that below splat occurs when the rmnet0 interface is deleted. Splat looks like: [ 53.254112][ C1] WARNING: CPU: 1 PID: 1192 at net/core/dev.c:8992 rollback_registered_many+0x986/0xcf0 [ 53.254117][ C1] Modules linked in: rmnet dummy openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nfx [ 53.254182][ C1] CPU: 1 PID: 1192 Comm: ip Not tainted 5.8.0-rc1+ #620 [ 53.254188][ C1] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 53.254192][ C1] RIP: 0010:rollback_registered_many+0x986/0xcf0 [ 53.254200][ C1] Code: 41 8b 4e cc 45 31 c0 31 d2 4c 89 ee 48 89 df e8 e0 47 ff ff 85 c0 0f 84 cd fc ff ff 0f 0b e5 [ 53.254205][ C1] RSP: 0018:ffff888050a5f2e0 EFLAGS: 00010287 [ 53.254214][ C1] RAX: ffff88805756d658 RBX: ffff88804d99c000 RCX: ffffffff8329d323 [ 53.254219][ C1] RDX: 1ffffffff0be6410 RSI: 0000000000000008 RDI: ffffffff85f32080 [ 53.254223][ C1] RBP: dffffc0000000000 R08: fffffbfff0be6411 R09: fffffbfff0be6411 [ 53.254228][ C1] R10: ffffffff85f32087 R11: 0000000000000001 R12: ffff888050a5f480 [ 53.254233][ C1] R13: ffff88804d99c0b8 R14: ffff888050a5f400 R15: ffff8880548ebe40 [ 53.254238][ C1] FS: 00007f6b86b370c0(0000) GS:ffff88806c200000(0000) knlGS:0000000000000000 [ 53.254243][ C1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 53.254248][ C1] CR2: 0000562c62438758 CR3: 000000003f600005 CR4: 00000000000606e0 [ 53.254253][ C1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 53.254257][ C1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 53.254261][ C1] Call Trace: [ 53.254266][ C1] ? lockdep_hardirqs_on_prepare+0x379/0x540 [ 53.254270][ C1] ? netif_set_real_num_tx_queues+0x780/0x780 [ 53.254275][ C1] ? rmnet_unregister_real_device+0x56/0x90 [rmnet] [ 53.254279][ C1] ? __kasan_slab_free+0x126/0x150 [ 53.254283][ C1] ? kfree+0xdc/0x320 [ 53.254288][ C1] ? rmnet_unregister_real_device+0x56/0x90 [rmnet] [ 53.254293][ C1] unregister_netdevice_many.part.135+0x13/0x1b0 [ 53.254297][ C1] rtnl_delete_link+0xbc/0x100 [ 53.254301][ C1] ? rtnl_af_register+0xc0/0xc0 [ 53.254305][ C1] rtnl_dellink+0x2dc/0x840 [ 53.254309][ C1] ? find_held_lock+0x39/0x1d0 [ 53.254314][ C1] ? valid_fdb_dump_strict+0x620/0x620 [ 53.254318][ C1] ? rtnetlink_rcv_msg+0x457/0x890 [ 53.254322][ C1] ? lock_contended+0xd20/0xd20 [ 53.254326][ C1] rtnetlink_rcv_msg+0x4a8/0x890 [ ... ] [ 73.813696][ T1192] unregister_netdevice: waiting for rmnet0 to become free. Usage count = 1 Fixes: 037f9cd ("net: rmnet: use upper/lower device infrastructure") Signed-off-by: Taehee Yoo <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
commit 2a762e9 upstream. There are two types of the lower interface of rmnet that are VND and BRIDGE. Each lower interface can have only one type either VND or BRIDGE. But, there is a case, which uses both lower interface types. Due to this unexpected behavior, lower interface leak occurs. Test commands: ip link add dummy0 type dummy ip link add dummy1 type dummy ip link add rmnet0 link dummy0 type rmnet mux_id 1 ip link set dummy1 master rmnet0 ip link add rmnet1 link dummy1 type rmnet mux_id 2 ip link del rmnet0 The dummy1 was attached as BRIDGE interface of rmnet0. Then, it also was attached as VND interface of rmnet1. This is unexpected behavior and there is no code for handling this case. So that below splat occurs when the rmnet0 interface is deleted. Splat looks like: [ 53.254112][ C1] WARNING: CPU: 1 PID: 1192 at net/core/dev.c:8992 rollback_registered_many+0x986/0xcf0 [ 53.254117][ C1] Modules linked in: rmnet dummy openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nfx [ 53.254182][ C1] CPU: 1 PID: 1192 Comm: ip Not tainted 5.8.0-rc1+ #620 [ 53.254188][ C1] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 53.254192][ C1] RIP: 0010:rollback_registered_many+0x986/0xcf0 [ 53.254200][ C1] Code: 41 8b 4e cc 45 31 c0 31 d2 4c 89 ee 48 89 df e8 e0 47 ff ff 85 c0 0f 84 cd fc ff ff 0f 0b e5 [ 53.254205][ C1] RSP: 0018:ffff888050a5f2e0 EFLAGS: 00010287 [ 53.254214][ C1] RAX: ffff88805756d658 RBX: ffff88804d99c000 RCX: ffffffff8329d323 [ 53.254219][ C1] RDX: 1ffffffff0be6410 RSI: 0000000000000008 RDI: ffffffff85f32080 [ 53.254223][ C1] RBP: dffffc0000000000 R08: fffffbfff0be6411 R09: fffffbfff0be6411 [ 53.254228][ C1] R10: ffffffff85f32087 R11: 0000000000000001 R12: ffff888050a5f480 [ 53.254233][ C1] R13: ffff88804d99c0b8 R14: ffff888050a5f400 R15: ffff8880548ebe40 [ 53.254238][ C1] FS: 00007f6b86b370c0(0000) GS:ffff88806c200000(0000) knlGS:0000000000000000 [ 53.254243][ C1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 53.254248][ C1] CR2: 0000562c62438758 CR3: 000000003f600005 CR4: 00000000000606e0 [ 53.254253][ C1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 53.254257][ C1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 53.254261][ C1] Call Trace: [ 53.254266][ C1] ? lockdep_hardirqs_on_prepare+0x379/0x540 [ 53.254270][ C1] ? netif_set_real_num_tx_queues+0x780/0x780 [ 53.254275][ C1] ? rmnet_unregister_real_device+0x56/0x90 [rmnet] [ 53.254279][ C1] ? __kasan_slab_free+0x126/0x150 [ 53.254283][ C1] ? kfree+0xdc/0x320 [ 53.254288][ C1] ? rmnet_unregister_real_device+0x56/0x90 [rmnet] [ 53.254293][ C1] unregister_netdevice_many.part.135+0x13/0x1b0 [ 53.254297][ C1] rtnl_delete_link+0xbc/0x100 [ 53.254301][ C1] ? rtnl_af_register+0xc0/0xc0 [ 53.254305][ C1] rtnl_dellink+0x2dc/0x840 [ 53.254309][ C1] ? find_held_lock+0x39/0x1d0 [ 53.254314][ C1] ? valid_fdb_dump_strict+0x620/0x620 [ 53.254318][ C1] ? rtnetlink_rcv_msg+0x457/0x890 [ 53.254322][ C1] ? lock_contended+0xd20/0xd20 [ 53.254326][ C1] rtnetlink_rcv_msg+0x4a8/0x890 [ ... ] [ 73.813696][ T1192] unregister_netdevice: waiting for rmnet0 to become free. Usage count = 1 Fixes: 037f9cd ("net: rmnet: use upper/lower device infrastructure") Signed-off-by: Taehee Yoo <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 2a762e9 upstream. There are two types of the lower interface of rmnet that are VND and BRIDGE. Each lower interface can have only one type either VND or BRIDGE. But, there is a case, which uses both lower interface types. Due to this unexpected behavior, lower interface leak occurs. Test commands: ip link add dummy0 type dummy ip link add dummy1 type dummy ip link add rmnet0 link dummy0 type rmnet mux_id 1 ip link set dummy1 master rmnet0 ip link add rmnet1 link dummy1 type rmnet mux_id 2 ip link del rmnet0 The dummy1 was attached as BRIDGE interface of rmnet0. Then, it also was attached as VND interface of rmnet1. This is unexpected behavior and there is no code for handling this case. So that below splat occurs when the rmnet0 interface is deleted. Splat looks like: [ 53.254112][ C1] WARNING: CPU: 1 PID: 1192 at net/core/dev.c:8992 rollback_registered_many+0x986/0xcf0 [ 53.254117][ C1] Modules linked in: rmnet dummy openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nfx [ 53.254182][ C1] CPU: 1 PID: 1192 Comm: ip Not tainted 5.8.0-rc1+ raspberrypi#620 [ 53.254188][ C1] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 53.254192][ C1] RIP: 0010:rollback_registered_many+0x986/0xcf0 [ 53.254200][ C1] Code: 41 8b 4e cc 45 31 c0 31 d2 4c 89 ee 48 89 df e8 e0 47 ff ff 85 c0 0f 84 cd fc ff ff 0f 0b e5 [ 53.254205][ C1] RSP: 0018:ffff888050a5f2e0 EFLAGS: 00010287 [ 53.254214][ C1] RAX: ffff88805756d658 RBX: ffff88804d99c000 RCX: ffffffff8329d323 [ 53.254219][ C1] RDX: 1ffffffff0be6410 RSI: 0000000000000008 RDI: ffffffff85f32080 [ 53.254223][ C1] RBP: dffffc0000000000 R08: fffffbfff0be6411 R09: fffffbfff0be6411 [ 53.254228][ C1] R10: ffffffff85f32087 R11: 0000000000000001 R12: ffff888050a5f480 [ 53.254233][ C1] R13: ffff88804d99c0b8 R14: ffff888050a5f400 R15: ffff8880548ebe40 [ 53.254238][ C1] FS: 00007f6b86b370c0(0000) GS:ffff88806c200000(0000) knlGS:0000000000000000 [ 53.254243][ C1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 53.254248][ C1] CR2: 0000562c62438758 CR3: 000000003f600005 CR4: 00000000000606e0 [ 53.254253][ C1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 53.254257][ C1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 53.254261][ C1] Call Trace: [ 53.254266][ C1] ? lockdep_hardirqs_on_prepare+0x379/0x540 [ 53.254270][ C1] ? netif_set_real_num_tx_queues+0x780/0x780 [ 53.254275][ C1] ? rmnet_unregister_real_device+0x56/0x90 [rmnet] [ 53.254279][ C1] ? __kasan_slab_free+0x126/0x150 [ 53.254283][ C1] ? kfree+0xdc/0x320 [ 53.254288][ C1] ? rmnet_unregister_real_device+0x56/0x90 [rmnet] [ 53.254293][ C1] unregister_netdevice_many.part.135+0x13/0x1b0 [ 53.254297][ C1] rtnl_delete_link+0xbc/0x100 [ 53.254301][ C1] ? rtnl_af_register+0xc0/0xc0 [ 53.254305][ C1] rtnl_dellink+0x2dc/0x840 [ 53.254309][ C1] ? find_held_lock+0x39/0x1d0 [ 53.254314][ C1] ? valid_fdb_dump_strict+0x620/0x620 [ 53.254318][ C1] ? rtnetlink_rcv_msg+0x457/0x890 [ 53.254322][ C1] ? lock_contended+0xd20/0xd20 [ 53.254326][ C1] rtnetlink_rcv_msg+0x4a8/0x890 [ ... ] [ 73.813696][ T1192] unregister_netdevice: waiting for rmnet0 to become free. Usage count = 1 Fixes: 037f9cd ("net: rmnet: use upper/lower device infrastructure") Signed-off-by: Taehee Yoo <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
The r-pi is a Model B made in UK running up to date raspbian. No monitor or keyboard attached, just logged in with ssh, still booted into graphical shell. Overclocking is set to 'modest'. The easycap is the only external USB device. The SDCard is a type 10. Below how to reproduce the error:
Capture stops at the first frame by itself. PAL or NTSC (smaller image size but higher framerate, so possibly not much bandwidth change) does not matter. It seems not connected to power draw; I get the same results with the easycap plugged into the pi or a powered hub.
The first value in the avconv output (bytes received) is only ever slightly below the second value (bytes expected), but its not always the same. There are two video4linux messages in avconv output but there is only one buffer overrun in dmesg. If the fault is bandwidth based, probably the device can be set to capture in another resolution?
Curiously, streaming video4linux to file works somehow, although the dump file is of different size each time:
I read a lot about grabbing video on the r-pi, some people seem to have success with the stk1160 module (I remember to have seen a picture from avplay when connected in xrdp before the rpi-update from 3.10 to 3.12), some seem to be lucky with the easycap driver.
Kind regards
Peter
The text was updated successfully, but these errors were encountered: