having some issues with a video capture card and v4l. I'm on Fedora 29 x64, on kernel 4.20. I have libv4l and various utilities installed (paste with version numbering: https://pastebin.com/raw/gPHDYjdx )
the specific capture card is the Diamond VC500 (https://www.diamondmm.com/product/diamond-vc500-one-touch-video-capture-edit-stream/) which has the following chipset and appears to be properly supported on Linux: https://linuxtv.org/wiki/index.php/OTG102
the issue is that when I plug it into the computer, I get a v4l error when probing the device and it fails to register/mount it. I have verified t hat this capture card works fine on Windows once the proper driver is installed.
this is the dmesg output immediately after I plug it into the USB port. I've tested with 3 different USB ports and get the same result: https://pastebin.com/raw/hEk9d6iA
any ideas? the card appears to be supported fine since kernel ~3.16. it does appear to be recognized properly, and the drivers are loaded, but v4l spits it right out.
is there a way to output a v4l2 camera stream to the wpewebkit browser without transcoding?
mjpeg is what the camera outputs
mchehab: can you take a look at nukke's report above?
Looking at https://pastebin.com/raw/hEk9d6iA it fails with: "usb 1-3: couldn't get decoder output pad for V4L I/O"
hverkuil: there is a patch already for this driver from Brad
solving some media controller issue
with seems to be this case
[PATCH 1/2] cx231xx-video: Set media controller taint for analog
Ah, nice.
tfiga: gnurou_: any comments on https://www.spinics.net/lists/linux-media/msg146186.html ?
paulk-leonov: chromium adds the nali start code to each slice.
https://github.com/chromium/chromium/blob/master/media/gpu/v4l2/v4l2_h264_accelerator.cc#L391
mchehab: so building the git master should hopefully fix the issue?
nukke: no, I'm waiting for b-rad to submit a pull request with this patch
you should apply it on the top of git master
(if he didn't submit it yet)
I have a few PR to handle today
Sounds good. Is this a recent bug? I'm assuming this was working before right?
it is somewhat recent
ezequielg, thanks, that's what I remembered :)
paulk-leonov: in fact, I was wondering how we'd describe that.
ezequielg, I was thinking that requiring the full NAL + start bytes as part of the spec for h.264 would be the easiest
but that means having the slice header both in raw and parsed forms
ezequielg, and now ayaka brought up that some rockchip IPs (for HEVC) need other bitstream elements in raw form
and I don't think we can really have all elements both in raw and parsed form
mripard: I think at least for the scaling list it was explained before
sorry, reference lists*
rockchip decoder parses slice headers itself, so it wants the raw lists for the picture
but decoders which don't parse slice headers would want the lists reordered as per the slice headers
mchehab: Obrigado!
anytime