<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
***: camus has joined #linux-media
<br> eelstrebor has quit IRC (Quit: Ex-Chat)
<br> jm_h has joined #linux-media
<br> svarbanov has joined #linux-media
<br> ao2 has joined #linux-media
hverkuil: <u>jmondi</u>: re: https://patchwork.linuxtv.org/project/linux-media/list/?series=5847
<br> It's on my todo list, but I didn't manage to review it before my vacation. I hope to get to it this week, but it won't make it for 5.15 (too late for that).
***: djrscally has joined #linux-media
jmondi: <u>hverkuil</u>: no pressure! thanks for replying to such an old message :)
***: BrianG61UK_ has joined #linux-media
<br> BrianG61UK_ has quit IRC (Remote host closed the connection)
<br> BrianG61UK_ has joined #linux-media
<br> BrianG61UK__ has joined #linux-media
<br> BrianG61UK_ has quit IRC (Ping timeout: 480 seconds)
<br> BrianG61UK_ has joined #linux-media
<br> BrianG61UK__ has quit IRC (Ping timeout: 480 seconds)
<br> hiroh has joined #linux-media
<br> ao2 has quit IRC (Quit: Leaving)
<br> camus1 has joined #linux-media
tomba: subdev_do_ioctl_lock() takes vdev->lock if available, but I can't figure out how to set that lock. how is that supposed to be used by the drivers?
***: camus has quit IRC (Ping timeout: 480 seconds)
pinchartl: <u>tomba</u>: I don't think it's supposed to :-)
<br> it comes from the fact that we reuse video_device internally in v4l2_subdev
<br> (I had initially proposed splitting video_device in two, with a part that manages the devnode, and a part that manages the V4L2 video device API itself, but that wasn't accepted)
<br> there's a locking mechanism there, it has been blindly plumbed in subdev_do_ioctl_lock(), but I don't think we've ever tried to make use of it
tomba: <u>pinchartl</u>: ok, thanks
***: camus has joined #linux-media
<br> camus1 has quit IRC (Read error: Connection reset by peer)
hiroh: Can anyone answer to my question? If no driver actually support this control id, shall we make the specification about it at this time? https://lore.kernel.org/linux-media/CAO5uPHM-n9Rh6MPTNoyzOGR-jV5-qy3zj67MZuSM8uaAN=RNXw@mail.gmail.com/
hverkuil: <u>svarbanov</u>: ^^^
<br> <u>svarbanov</u>: didn't you have venus patches pending adding support for these controls?
***: hverkuil_ has joined #linux-media
<br> hverkuil has quit IRC (Read error: Connection reset by peer)
<br> hverkuil_ has quit IRC (Quit: ZNC 1.8.2+deb2+b1 - https://znc.in)
<br> hverkuil has joined #linux-media
dv_: does anybody know if there are newer USB cameras that use USB3 to transmit raw 1080p/4K frames? USB3 should have sufficient bandwidth
<br> so far, the cams that I used were USB2 based, and I had to rely on mjpeg transmission to get 30fps at 1080p
<br> and if there are USB3 cameras, do these require something newer than the UVC standard?
<br> I suppose the linux uvcvideo implementation should support UVC 1.5 .. ?
pinchartl: <u>dv_</u>: the logitech brio can do 1080p @30fps in YUYV according to its UVC descriptors
<br> I'm sure there are others
dv_: ah - yes, that's a USB3 one
pinchartl: it's supported by the uvcvideo driver
dv_: great, thanks
pinchartl: there's the logitech streamcam too, 1080p @30fps (and 2304x1296 @5fps)
dv_: oh, and can usb3 cams stream frames as a whole instead of per-packet?
pinchartl: how do you mean ?
dv_: more specifically, can captured frames in USB3 cams be read by simple DMA (that is, not scatter-gather)?
pinchartl: USB is packet-based
<br> no
<br> there will always be a memcpy
dv_: so, any SoC that does not have SG-DMA will use CPU% when capturing frames via USB
pinchartl: that's inherent to the uvc protocol
dv_: significant CPU% that is
pinchartl: even USB controllers that have scatter-gather DMA support won't help
<br> packets are prefixed by a header
<br> the size of the header is variable and unknown in advance
dv_: oh so they need to be parsed
pinchartl: yes
<br> the data portion of each packet has to be copied to the image buffer
dv_: so ... capturing with USB3 webcams that deliver something like 1080p60 will always cause significant CPU usage
pinchartl: it would be possible to implement a USB host controller with support for UVC, splitting headers and image data in two different buffers, but I'm not aware of such a device
dv_: on an embedded SoC that is
pinchartl: yes, it will always cause significant CPU usage
dv_: hm I suppose that is an argument for using MJPEG even in newer webcams then
pinchartl: we've actually deferred the copy to a workqueue in order to parallelize copy operations between multiple CPUs
<br> for the logitech brio
<br> a single CPU wasn't able to cope
dv_: since the MJPEG decoding can be done by a hw decoder and decode into physically contiguous mem
***: camus1 has joined #linux-media
dv_: I'd have thought that USB3 and newer would introduce _something_ to make it easier to use bulk DMA transfers
***: camus has quit IRC (Ping timeout: 480 seconds)
broonie: I guess you could use a generic DMA controller to pick the buffers apart too, though the setup/interrupt costs might be too heavy to be worthwhile.
pinchartl: the buffers are fairly small :-S
broonie: Not small enough!
pinchartl: :-)
***: camus1 has quit IRC (Remote host closed the connection)
<br> camus has joined #linux-media
<br> camus has quit IRC (Remote host closed the connection)
<br> camus has joined #linux-media
<br> ao2 has joined #linux-media
<br> ao2 has quit IRC (Quit: Leaving)
<br> gouchi has joined #linux-media
<br> NiksDev has joined #linux-media
<br> eelstrebor has joined #linux-media
<br> camus has quit IRC (Read error: Connection reset by peer)
<br> camus has joined #linux-media
<br> ao2 has joined #linux-media
<br> camus has quit IRC (Remote host closed the connection)
<br> camus has joined #linux-media
<br> ao2 has quit IRC (Quit: Leaving)
<br> camus1 has joined #linux-media
<br> camus1 has quit IRC (Remote host closed the connection)
<br> camus has quit IRC (Ping timeout: 480 seconds)
<br> camus has joined #linux-media
<br> gouchi has quit IRC (Remote host closed the connection)
<br> jm_h has quit IRC (Remote host closed the connection)
<br> djrscally has quit IRC (Ping timeout: 480 seconds)