| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | mchehab has quit IRC (Ping timeout: 260 seconds)
Killerkid_ has quit IRC (Ping timeout: 252 seconds) | [01:23] |
| .................................................................. (idle for 5h27mn) | ||
| al has quit IRC (Ping timeout: 264 seconds) | [06:53] | |
| .................... (idle for 1h37mn) | ||
| paulk-leonov has quit IRC (Ping timeout: 252 seconds) | [08:30] | |
| .............. (idle for 1h8mn) | ||
| hverkuil | pH5: I assume you want to add 'capture colorspace conversion' afterwards? So the initial driver is without this feature?
Not a problem, I just want to know what I can expect. | [09:38] |
| pH5 | hverkuil: yes, I'm just now writing a reply to the RFC thread.
I have just realized that I have to limit capture pixel formats depending on output ycbcr_enc and quantization. If the driver is fed limited range RGB, it can't convert it to anything but limited range RGB, currently. | [09:49] |
| *** | mszyprow has quit IRC (Ping timeout: 245 seconds) | [09:55] |
| ............. (idle for 1h2mn) | ||
| hverkuil | pH5: that's a HW limitation?
Why can't it convert this? It shouldn't be a problem with a matrix + offset vector. | [10:57] |
| ........ (idle for 38mn) | ||
| pH5 | hverkuil: no, that's just a driver limitation. alternatively, I could add another set of coefficients for limited range RGB.
I think V4L2_YCBCR_ENC_BT2020_CONST_LUM has the same issue, though. | [11:37] |
| ........... (idle for 54mn) | ||
| *** | jmleo has quit IRC (Ping timeout: 240 seconds) | [12:31] |
| ...... (idle for 29mn) | ||
| ezequielg | hverkuil: we are working on adding a kernelci job to run v4l2-compliance -s on some virtual devices, on a qemu instance. the plan is to send reports to the media ML, so we can get some feedback from the community. | [13:00] |
| ............. (idle for 1h4mn) | ||
| *** | bingbu has quit IRC (Ping timeout: 244 seconds) | [14:04] |
| paulk-leonov | hverkuil, I'm having a pretty big issue with buffer allocation after the change you (rightfully) requested regarding queue setup
hverkuil, what's happening is that the requested number of distinct buffers to allocate is taken from f->fmt.pix_mp.num_planes because we want our 2 (logical) planes contiguous, that would need to be set to 1 so the associated size must match the sum of the both planes | [14:05] |
| hverkuil | ezequielg: nice! | [14:07] |
| paulk-leonov | then, there's about no way for userspace to figure out the offset to the second logical plane in that buffer, except explicitly knowing how to calculate that offset
(before that, the fmt num_planes was 2 and each offset was set for the logical planes) I realize this was wrong in the first place overriding the values in cedrus_queue_setup would end up in requesting 1 plane while not touching the pixfmt description (that still had 2 planes described) so right now I'm thinking of always declaring 1 plane for V4L2_PIX_FMT_NV12 and let userspace calculate the right offset to the start of the 2nd logical plane would that make sense? (I'm not sure my description of the problem is very clear, either) | [14:08] |
| hverkuil | num_planes is a horrible misnomer: it refers to the number of buffers to allocate for the planes of a frame.
Typically it is 1 if all planes are in a single buffer, 2 if you have separate luma and chroma planes and in rare cases 3 if you have Y, Cb and Cr planes. num_planes is pixel format dependent, and queue_setup should reject (when called with CREATE_BUFS) a different num_planes value compared to the current format. | [14:13] |
| paulk-leonov | hverkuil, alright, so that should definitely be 1 in my case | [14:15] |
| hverkuil | So NV12 sets num_planes to 1, always. | [14:15] |
| paulk-leonov | so it's normal to expect userspace to know where luma starts there, then? | [14:15] |
| hverkuil | NV12M sets it to 2. | [14:15] |
| paulk-leonov | chroma* | [14:15] |
| hverkuil | YUV444M sets it to 3 (three buffers, one for each plane) | [14:16] |
| paulk-leonov | I see
so sizeimage also concerns the size of the buffer (not each logical plane)? | [14:16] |
| hverkuil | The description of the pixelformat (like NV12) describes how planes in a single buffer are organized. | [14:16] |
| paulk-leonov | fair enough
thanks hverkuil, I'll try to post a new cedrus version later today | [14:17] |
| hverkuil | For _MPLANE formats sizeimage is per plane (struct v4l2_pix_format_mplane) | [14:17] |
| ezequielg | paulk-leonov: if it helps, you can take a look at the rockchip vpu driver. | [14:18] |
| hverkuil | I wish we could go back in time and give these things better names, it's really confusing. | [14:18] |
| paulk-leonov | ah! so num_planes is not the number of elements in plane_fmt then | [14:19] |
| hverkuil | Just remember that when V4L2 talks about 'multiplanar' then what we really mean is "multiple buffers per frame, each buffer containing one or more planes" | [14:19] |
| paulk-leonov | I see
that's a good way to summarize it | [14:19] |
| mjourdan | just like the "OUTPUT" queue, I keep having to do the translation to "input/src" when doing m2m work | [14:19] |
| hverkuil | Yes, num_planes is the number of elements in plane_fmt.
num_planes should be 'num_bufs_per_frame' or something like that :-( | [14:19] |
| paulk-leonov | mjourdan, I call them source/destination everywhere I can :) | [14:20] |
| mjourdan | Yeah, that's a good name, especially with most helpers using "src" and "dst" | [14:21] |
| ........ (idle for 35mn) | ||
| *** | quopax has left | [14:56] |
| ..... (idle for 22mn) | ||
| rpici | Hello. I have an app that accesses a V4L2 device from two different threads. One thread fetches frames from the device if the device is streaming. The other thread periodically toggles the V4L stream on and off. To prevent race conditions I use a mutex. Under the mutex each thread calls whatever it needs to call to do its job. The fetcher thread locks the mutex, checks to see if the device is streaming, fetches a frame if it is, an | [15:18] |
| paulk-leonov | hverkuil, given that I'm always going to need a single buffer, does it still make sense to use the MPLANE API? | [15:19] |
| rpici | The toggler thread locks the mutex and toggles whether the device is streaming. My issue is I sometimes see errors with VIDIOC_STREAMON. The error I see is EFBIG (File too large). I've found that if I add a sleep of 1 second in the start_streaming() call, in between the VIDIOC_QBUF calls and the VIDIOC_STREAMON call, the crash goes away. I'm not sure why. | [15:21] |
| hverkuil1 | paulk-leonov: probably not. | [15:22] |
| paulk-leonov | okay so I'll convert everything to the single-planar API | [15:23] |
| rpici | I said "start_streaming()" but I meant "start_capturing()", based on this example: https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/capture.c.html
Can anyone help me figure out what causes the crash and why a sleep seems to fix it? I'd like to fix the actual problem without having to resort to using a sleep as a bandaid. | [15:25] |
| hverkuil1 | rpici: what driver are you using?
and what kernel version? | [15:32] |
| rpici | hverkuill: how do I determine the driver? for my kernel, uname -a says: Linux cubox-i 3.14.14-cubox-i #14 SMP Tue Jul 28 10:46:10 CDT 2015 armv7l GNU/Linux | [15:33] |
| hverkuil1 | you have v4l2-ctl installed? Then run v4l2-ctl -D to see the driver name
But this is a 3.14 kernel for an imx freescale, so that (I'm sure) is running crap drivers from Freescale that we do not support. | [15:33] |
| rpici | v4l2-ctl: command not found, v4l2-ctl also doesn't seem to be in my apt-get repo | [15:35] |
| hverkuil1 | Apparently the driver returns EFBIG in some cases, so you're best bet is to download the kernel source and start digging in the driver code.
Probably a package v4l-utils. -D just executes the VIDIOC_QUERYCAP ioctl. You can do that in your application as well and show the driver field. | [15:36] |
| rpici | Ok. I'll do that and find the driver field. bbl. Thank you for your help. | [15:37] |
| *** | benjiG has left | [15:45] |
| .... (idle for 18mn) | ||
| rpici | hverkuil1: driver: uvcvideo, card: UVC Camera (046d:0825), bus_info: usb-ci_hdrc.0-1.4.2 | [16:03] |
| hverkuil1 | rpici: no idea where EFBIG comes from. uvc is part of the 3.14 kernel, but it doesn't return EFBIG.
(so you're just running a uvc webcam, not the freescale driver, that's good). | [16:08] |
| rpici | Here's a snippet from my code: https://pastebin.com/UsnCRPZE. This sometimes (but not always) results in an error: "Error: void V4L2CaptureDevice::start_capturing(): VIDIOC_STREAMON: File too large" | [16:17] |
| hverkuil1 | I think EFBIG comes from the usb subsystem.
Sorry, I know nothing about that. | [16:18] |
| rpici | Ok. I guess I'll take a dive into the kernel source. Thanks for your help. | [16:23] |
| ......................................... (idle for 3h22mn) | ||
| ezequielg | hverkuil1: I forgot to put a "Media summit" prefix to the RFP for the test discussion. Wonder if the RFP was still properly noticed. | [19:45] |
| .... (idle for 15mn) | ||
| *** | Guest26088 is now known as koike | [20:00] |
| ....... (idle for 34mn) | ||
| paulk-leonov | hverkuil1, by the way, I'm getting a v4l2-compliance error on VIDIOC_G_FMT because it returns a zero width/height
since that's before setting a format, I'm not sure what to do abou tit the hardware state is "unconfigured" at this point, but returning EINVAL in the driver shall indicate that the format is not supported, not that the hardware is not configured also try_ext_ctrls fails because the default value for the control (that v4l2-compliance uses) is (rightfully) invalid | [20:34] |
| ezequielg | paulk-leonov: G_FMT fails on what queue? | [20:48] |
| paulk-leonov | ezequielg, both of them
the problem is that there is no hardware state | [20:48] |
| ezequielg | that's definitely wrong.
just pick a default state. well, i won't argue about this making a lot of sense, or little, or no sense... but on the drivers I've written, they simply have a default state. so you may open() and read(). (iirc) now, we don't have a stateless spec (yet). but for capture drivers, the drivers always have a default state. you can check what rockchip vpu does | [20:48] |
| paulk-leonov | ezequielg, I see, thanks for the explanation | [20:56] |
| ezequielg | paulk-leonov: how about the try_ext_ctrls? | [20:58] |
| paulk-leonov | ezequielg, that one is because the default control value (all zeroed) is not valid
I'm not sure what to think about it | [20:59] |
| *** | ntrrgc has quit IRC (Ping timeout: 252 seconds) | [21:02] |
| paulk-leonov | well, that can probably be fixed later | [21:04] |
| ezequielg | can you show me the error? I am curious about that, as I've never seen it.
the G_FMT one, I know it very well... it was a pain to comply with that. | [21:07] |
| paulk-leonov | it just says "fail: v4l2-test-controls.cpp(659): try_ext_ctrls returned an error (22)"
which originates from std_validate I think | [21:08] |
| ezequielg | oh, i see.
because there's some validation for those controls. | [21:15] |
| paulk-leonov | yes | [21:15] |
| ezequielg | but you set no default value | [21:15] |
| paulk-leonov | right | [21:15] |
| ezequielg | well, just set a default value and it'll pass i think.
the test does G_CTRL/S_CTRL. | [21:15] |
| paulk-leonov | yes but that seems even more far-fetched than setting a default value for the format | [21:16] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |