Video capture from stk1160 device fails

[hungerburg]

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:

$ uname -a
Linux raspberrypi 3.12.21+ #689 PREEMPT Wed Jun 11 21:45:12 BST 2014 armv6l GNU/Linux
$ v4l2-ctl --set-standard=5
$ v4l2-ctl --get-fmt-video
Format Video Capture:
    Width/Height  : 720/576
    Pixel Format  : 'UYVY'
    Field         : Interlaced
    Bytes per Line: 1440
    Size Image    : 829440
    Colorspace    : Broadcast NTSC/PAL (SMPTE170M/ITU601)
$ avconv -v verbose -f video4linux2 -i /dev/video0 -b 5M -y /tmp/KK.flv
[…]
avconv version 0.8.10-6:0.8.10-1+rpi1, Copyright (c) 2000-2013 the Libav developers
[…]
[video4linux2 @ 0xcaa720] [4]Capabilities: 85000001
[video4linux2 @ 0xcaa720] Querying the device for the current frame size
[video4linux2 @ 0xcaa720] Setting frame size to 720x576
[video4linux2 @ 0xcaa720] The v4l2 frame is 828416 bytes, but 829440 bytes are expected
[…]
Press ctrl-c to stop encoding
[video4linux2 @ 0xcaa720] The v4l2 frame is 826906 bytes, but 829440 bytes are expected
frame=    0 fps=  0 q=0.0 Lsize=       0kB time=10000000000.00 bitrate=   0.0kbits/s    
video:0kB audio:0kB global headers:0kB muxing overhead nan%
$ dmesg
[…]
[81714.038072] usb 1-1.3.2: New device Syntek Semiconductor USB 2.0 Video Capture Controller @ 480 Mbps (05e1:0408, interface 0, class 0)
[…]
[81283.278685] stk1160: streaming started
[81283.431336] URB packet 0, status -63 [Buffer error (overrun)].
[81283.460993] stk1160: killing 8 urbs...
[…]

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:

$ sudo dmesg -c
$ v4l2-ctl --stream-mmap=3 --stream-count=100 --stream-to=/tmp/KK.dat
<<<<<<<<<<<<<<<<<<<<<<<<<< 25 fps
<<<<<<<<<<<<<<<<<<<<<<<< 23 fps
<<<<<<<<<<<<<<<<<<<<<<<<<< 25 fps
<<<<<<<<<<<<<<<<<<<<<<<<

$ du /tmp/KK.dat 
80732   /tmp/KK.dat
$ dmesg | grep -c overrun
9

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

[P33M]

When you say you get a frame before it stops, is the frame garbled or readable?

[hungerburg]

The file captured from avconv command above (/tmp/KK.flv) is empty. I do not get to see how the (short) frame looks like.

[hungerburg]

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.raw

If 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:

[P33M]

Can you post a lsusb -t?

[hungerburg]

pi@raspberrypi ~ $ 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/5p, 480M
        |__ Port 1: Dev 3, If 0, Class=vend., Driver=smsc95xx, 480M
        |__ Port 3: Dev 4, If 0, Class=hub, Driver=hub/4p, 480M
            |__ 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

[P33M]

If you add the parameter dwc_otg.fiq_fsm_mask=0x3 to /boot/cmdline.txt (and reboot), is the capture different/improved/?

[hungerburg]

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?

[P33M]

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?

[hungerburg]

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):

$ guvcview -f uyvy -s 720x576 -w 0 -c 1
[…]
video device: /dev/video0 
Init. stk1160 (location: usb-bcm2708_usb-1.3.3)
{ pixelformat = 'UYVY', description = '16 bpp YUY2, 4:2:2, packed' }
VIDIOC_ENUM_FRAMESIZES - Error enumerating frame sizes: Inappropriate ioctl for device
  Unable to enumerate frame sizes.
: Inappropriate ioctl for device
{ pixelformat = 'RGB3', description = 'RGB3' }
{ ?GSPCA? : width = 720, height = 576 }
fmtind:2 fsizeind: 1
{ pixelformat = 'BGR3', description = 'BGR3' }
{ ?GSPCA? : width = 720, height = 576 }
fmtind:3 fsizeind: 1
{ pixelformat = 'YU12', description = 'YU12' }
{ ?GSPCA? : width = 720, height = 576 }
fmtind:4 fsizeind: 1
{ pixelformat = 'YV12', description = 'YV12' }
{ ?GSPCA? : width = 720, height = 576 }
fmtind:5 fsizeind: 1
vid:05e1 
pid:0408 
driver:stk1160
checking format: 1498831189
Unable to set 1/25 fps
VIDIOC_S_PARM error: Inappropriate ioctl for device
fps is set to 1/25
drawing controls

control type: 0x00000006 not supported
Segmentation fault

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/.

[hungerburg]

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.

[hungerburg]

Will the Model B+ make a difference in this regard or is this still handicapped on high throughput?

[P33M]

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.

[sassmann]

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.
Here's some info about the setup

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!

[knowncolor]

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/.

[npp1993]

@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?