| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| dlynes | If I run a VIDIOC_QUERYCAP to determine whether I should be using V4L2_CAP_VIDEO_CAPTURE or V4L2_CAP_VIDEO_CAPTURE_MPLANE for VIDIOC_ENUM_FMT, and supply an index of 0, would there be a reason why VIDIOC_ENUM_FMT fails every time? | [04:29] |
| ........................................................ (idle for 4h35mn) | ||
| *** | fritzfritz has quit IRC (Read error: Connection reset by peer)
dagmcr has quit IRC (Read error: Connection reset by peer) ezequielg has quit IRC (Ping timeout: 260 seconds) ntrrgc has quit IRC (Ping timeout: 244 seconds) | [09:04] |
| .............. (idle for 1h8mn) | ||
| ayaka | ndufresne, actually per slice decoding is verified, but I don't know what the problem is here you need to figure out | [10:14] |
| ........ (idle for 38mn) | ||
| tfiga | dlynes: what driver is that?
Actually, for ENUM_FMT and other ioctls you have to use V4L2_BUF_TYPE macros, not CAP | [10:52] |
| ........................... (idle for 2h10mn) | ||
| dlynes | Are there any circumstances under which VIDIOC_ENUM_FMT would fail? | [13:05] |
| .... (idle for 19mn) | ||
| tfiga | https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/vidioc-enum-fmt.html
dlynes: ^ | [13:24] |
| dlynes | tfiga: I've already read that page
tfiga: When I query the driver from a small piece of sample code, it works fine, but inside of an application, it does not | [13:32] |
| tfiga | dlynes: the reasons for the error code stated there are the only ones
of course it's possible that a driver doesn't implement something correctly and thus I asked what is your driver I also suggested one reason of the failure, based on what you mentioned before (the mismatch of V4L2_CAP and V4L2_BUF_TYPE macros) have you checked that? | [13:33] |
| ...................... (idle for 1h48mn) | ||
| ndufresne | ayaka: in the Linux kernel, we need from a kernel point of view, guaranty that the HW time can be sliced fairly, what we call slice mode in the kernel is linux specific, it means that it's a HW that can decoder 1 slice from let's say stream A, then another from stream B, and come back to decoding another slice of stream A later on
As far as our testing have gone, rkvdec was not capable of doing that, as after it reached that end of the slice, we'd have to continue and finish stream A frame before being able to move on to stream B | [15:23] |
| ayaka | ndufresne, have you tried to reset the hardware ? | [15:25] |
| ndufresne | ayaka: I believe bbrezillon did many trial and error, and we could only conclude that some state was remaining in the HW | [15:25] |
| ayaka | I wonder what the virtual height is you configured for it | [15:26] |
| ndufresne | what we had is that when we scheduled let's say slice 2, the HW would always return ASO error
ayaka: I'm not sure that any Rockchip VPU users do care about the latency gain of such feature though, so is it really worth it ? I mean, frame based is more efficient and works well | [15:26] |
| ayaka | ndufresne, aso error？ are you talking about the rk vdpu ? | [15:28] |
| ndufresne | I believe that was rkvdec, perhaps it was the vdpu (the hantro based one) | [15:29] |
| ayaka | I was not talking about that hantro one | [15:29] |
| ndufresne | ayaka: if someone cares, he can figure-out, I personally don't need it, that is just about adding extra capabilities | [15:29] |
| ayaka | check sw_h264_frame_orslice in rkvdec_swreg2_sysctrl | [15:30] |
| ndufresne | again, I don't have immediate need of it, if someone needs it and they ping me, I'll report back that you said it might be possible
ayaka: what I remember while working with bbrezillon, is that at some point we manage to use the slice mode, so that mode was working, but it had some limitations | [15:31] |
| ayaka | anyway, let he ask me about that | [15:32] |
| ndufresne | ayaka: I think this is something to dig into for higher end video streaming solution, I'm working a bit on the mid-end category right now
the plus side, is that there is no plumbing needed, since the API supports it for cedrus it's a driver thing | [15:33] |
| ........................................... (idle for 3h34mn) | ||
| dlynes | tfiga: sorry...I must have missed that...got too much spam from another channel
tfiga: I did change that from V4L2_BUF_TYPE_VIDEO_CAPTURE to V4L2_CAP_VIDEO_CAPTURE tfiga: I have no idea what driver it's using...didn't know I could select one. It's the Microsoft LifeCam HD-3000, but this problem occurs with the Logictech c920 as well | [19:08] |
| tfiga | do you mean from V4L2_CAP_VIDEO_CAPTURE to V4L2_BUF_TYPE_VIDEO_CAPTURE? | [19:14] |
| dlynes | tfiga: No. V4L2_BUF_TYPE_VIDEO_CAPTURE to V4L2_CAP_VIDEO_CAPTURE | [19:14] |
| tfiga | V4L2_CAP_VIDEO_CAPTURE is what is returned by VIDIOC_QUERYCAP
and V4L2_BUF_TYPE_VIDEO_CAPTURE is what must be used with VIDIOC_ENUM_FMT | [19:15] |
| dlynes | Ok...the BUF one is the one that was in there originally and wasn't working | [19:15] |
| tfiga | + the _MPLANE variants | [19:15] |
| dlynes | I'll put that back in
tfiga: Yes. I did V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_CAPTURE_MPLANE tfiga: when populating the caps structure | [19:15] |
| tfiga | for VIDIOC_QUERYCAP, the v4l2_capability struct is to be filled by the kernel, not the application
the application then checks what the kernel filled in, e.g. whether it has V4L2_CAP_VIDEO_CAPTURE or V4L2_CAP_VIDEO_CAPTURE_MPLANE then the application must use the corresponding (one) V4L2_BUF_TYPE macro for VIDIOC_ENUM_FMT the driver might report supporting both plain and MPLANE variants, but the application must use one with further ioctls | [19:17] |
| dlynes | tfiga: Have used the following code for setting the format's type then: fmt.type = (caps->capabilities & V4L2_CAP_VIDEO_CAPTURE) ? V4L2_BUF_TYPE_VIDEO_CAPTURE : (caps->capabilities & V4L2_CAP_VIDEO_CAPTURE_MPLANE) ? V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE : 0 | [19:21] |
| tfiga | okay, that looks fine for me | [19:23] |
| dlynes | tfiga: still results in a -1 returnv value from ioctl | [19:23] |
| tfiga | do you see any errors in the kernel log? | [19:23] |
| dlynes | didn't know to check that...will check | [19:23] |
| tfiga | you can run the `dmesg` command
also, I assume the camera works with some sample camera capture apps, like qv4l2? | [19:23] |
| dlynes | tfiga: It also works with v4l2-ctl -d0 --list-formats-ext | [19:25] |
| tfiga | do you initialize the other fields of the struct to zero? | [19:26] |
| dlynes | tfiga: Yes. memset.
tfiga: nothing in dmesg or syslog tfiga: what's really weird is I wrote some test code that just opens the device, queries capabilities, queries formats, closes the device and exits tfiga: that sample code works perfectly | [19:26] |
| tfiga | dlynes: any chance that the other application has a threading issue and it ends up closing your device file descriptor or something?
I guess you can check what the errno code points to | [19:34] |
| dlynes | Yeah, I thought of that, but the only threads that exist at that point are the two threads that are created automatically when an application is bound to qt
So, none of the threads I specifically create have been created at that point, and no callbacks have been registered yet Realized in my sample code that was working, I was calling the cap versions of the macros instead of hte buf type versions. When I changed it to buf type versions as well, it stopped working So, I'm going through what got populated in the capabilities and device_caps fields to see what capabilities it actually has nvm...I was being stupid...comparing the return value of ioctl to something >0 in the test code so, yes..the test code is still working...application code is not | [19:37] |
| tfiga: I'm doing something slightly different in the test code...will see if that makes all the difference
tfiga: I didn't writeh the original code, and I'm a little more pedantic than the original programmers tfiga: I was bitwise ORing V4L2_CAP_STREAMING and V4L2_CAP_READWRITE with the capabilities before determining whether to use CAPTURE, or CAPTURE_MPLANE | [19:48] | |
| tfiga | also, are you sure that the other application opens the right device node? on newer kernels some cameras expose two, one for video and one for meta data | [19:51] |
| dlynes | tfiga: I twigged on that when you mentioned non-mplane and mplane could both be set
tfiga: I have /dev/video0 and /dev/video1...figured the /dev/video1 was a phantom device | [19:51] |
| tfiga | the meta one wouldn't have CAP_VIDEO_* returned from QUERYCAP, though
you can also do one more thing there is a debug knob in sysfs /sys/class/video4linux/videoX/dev_debug | [19:52] |
| dlynes | tfiga: I know nothing about v4l; I was just asked to fix broken code | [19:52] |
| tfiga | if you write a bit mask there, e.g. 255, it would print the ioctls in the kernel log | [19:52] |
| dlynes | tfiga: cool. That'll be helpful
done Perfect. I love that feature. don't need to run it inside of gdb now and it dumps out pixelformat and description in readable formats tfiga: thank you so much. found the bug tfiga: the application was reading the meta data, not the camera | [19:53] |
| tfiga | you're welcome | [20:01] |
| dlynes | tfiga: that dev_debug thing was just what the doctor ordered | [20:01] |
| tfiga | glad that you got it to work :) | [20:01] |
| dlynes | tfiga: well...haven't confirmed it's working yet :o
Yep...working now...thank you so much | [20:02] |
| tfiga | cool
np | [20:03] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |