| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| hverkuil | ezequielg: ping | [09:02] |
| ................................... (idle for 2h52mn) | ||
| grkblood13 | does V4L maintain dvbv5-tools? | [11:54] |
| ezequielg | hverkuil: hello | [11:58] |
| grkblood13 | ok, it seems it resides in v4l-utils after a little digging, so ill ask the same thing I asked in #linuxtv. Whenever I run dvbv5-scan ~/dvb-test it sits idle for about 5 seconds and then returns with no results. I can confirm other scanning tools work. Any idea on why this tool isn't returning anything? | [12:05] |
| hverkuil | ezequielg: Hi! I posted a PR for the h264 cleanup patches, but I had one more question:
Currently the API supports two modes: one frame per buffer or one slice per buffer, right? As I understand it there are plans to support multiple slices per buffer, but that requires variable length arrays in the control framework, correct? | [12:12] |
| ezequielg | Yes, it does, because want to avoid always passing 16 slices per request.
Note however that cedrus will need a lot of changes to work that way. We might want to merge some traces first, to get performance metrics of the benefits of it. | [12:17] |
| ..... (idle for 22mn) | ||
| hverkuil | ezequielg: I assume a new slice array control will be introduced when we go to multiple slices per buffer?
and no other changes are needed for the other h264 stateless controls? | [12:41] |
| ezequielg | That's right
Do you think we'll likely see the need to support MVC? | [12:49] |
| hverkuil | I do have a 3D capable TV and I do have MVC mkv files. I would guess that if someone wants to use this for high-end video streaming, then yes, they would want hardware MVC support.
That said, we still don't support 'regular' 3D in V4L2, so I am not holding my breath. | [12:52] |
| I still would like to have some idea of the impact of MVC on the existing API. | [12:58] | |
| ezequielg | I'd have to think some more about it and draft a plan. | [13:02] |
| ................ (idle for 1h17mn) | ||
| tfiga | ezequielg: 3D TVs have been pronounced dead...
I think it's something nice to have, but I wouldn't expect any big interest for it in the last couple of years, we haven't had a single query about in in Chrome OS sailus: I wonder if __v4l2_async_notifier_parse_fwnode_ep() shouldn't check if the remote device isn't available, rather than the port parent (code: https://elixir.bootlin.com/linux/v5.9-rc2/source/drivers/media/v4l2-core/v4l2-fwnode.c#L879) we happen to have some hardware variants sharing the DT, but with sensor nodes enabled and disabled depending on the variant | [14:19] |
| ezequielg | tfiga: thanks a lot for the input | [14:21] |
| tfiga | ezequielg: https://en.wikipedia.org/wiki/3D_television#Decline has some references to various hints suggesting that 3D is going away
of course there is always a chance for the trend to reverse :) the future is unpredictable | [14:22] |
| ezequielg | hverkuil: is it guaranteed by the control api , that the values set by a control that is part of a request, will persist and apply to future requests? I think it's very useful if the user can set the active sps , as defined by the h264 spec, and then rely on it being active. | [14:23] |
| tfiga | ezequielg: the request only carries the command of setting a control
the values are stored in the driver control handler | [14:24] |
| ezequielg | Yes, but currently the framework stores the value set (per context)
If we could guarantee this is expected behavior it would avoid passing the same values over and over | [14:25] |
| tfiga | when a request is executed, the controls are copied to the driver control handler
of course if the driver uses the control framework helpers at least that was the expectation when the API was being designed that a request is just a set of operations to be executed together, possibly atomically and not a full copy of state on its own | [14:26] |
| hverkuil | ezequielg: if you do not set a control in a request, then the driver will use the current value (i.e. that in the top-level control handler). Basically that is what v4l2_ctrl_request_setup() does: it copies the controls set in the request to the top-level controls. If it is not in the request, then it is unchanged. | [14:28] |
| ................... (idle for 1h32mn) | ||
| sailus | tfiga: Status is defined for devices, not for ports.
The sensor device should not be enabled if it's not really there. | [16:00] |
| tfiga | sailus: I think that's what I wrote :) | [16:01] |
| sailus | Hmm. | [16:01] |
| tfiga | port parent == device, remote device == device :) | [16:01] |
| sailus | That check is already done, isn't it? | [16:01] |
| tfiga | currently the code only checks if the device the port belongs to is enabled
it doesn't seem to check if the remote device is enabled | [16:01] |
| sailus | Ah. | [16:02] |
| tfiga | but maybe I'm misreading the code? | [16:02] |
| sailus | This isn't a great way to parse the endpoints btw.
But there can also be a bug in the code. | [16:02] |
| tfiga | well, I think we can fix it if it's a bug, but I was wondering about the intention | [16:03] |
| sailus | That looks like a bug indeed. | [16:05] |
| tfiga | Okay, we'll send a fix once we get to actually testing it on a device :)
Thanks! | [16:06] |
| sailus | It should be checking the availability of the remote device, not the local one --- the parsing is initiated by the driver of the local device, so the existing check is always true. | [16:06] |
| tfiga | Okay, thanks for confirming :) | [16:10] |
| sailus | tfiga: Where do you need that function btw.?
I'd rather get rid of it altogether... | [16:21] |
| ....... (idle for 34mn) | ||
| pinchartl | hverkuil: ping | [16:55] |
| hverkuil: I'm puzzled by the v4l2-compliance test that ensures that VIDIO_ENUM_FRAMESIZES reports no sizes when the device can scale
where does that requirement come from ? | [17:06] | |
| (fail: v4l2-test-formats.cpp(1892): node->can_scale && node->frmsizes_count[v4l_format_g_pixelformat(&cur)]) | [17:12] | |
| hverkuil | pinchartl: if there is no scaler, then calling S_FMT will select one of the discrete framesizes. If there is a scaler, then what does S_FMT mean? Leave it up to the driver to select one of the discrete framesizes and then scale? It's undefined. If someone would be willing to define how this works in the API, then this restriction can be lifted.
Basically it is a weird combinations of features: why would you have discrete framesizes while at the same time you have a scaler? | [17:26] |
| .... (idle for 18mn) | ||
| pinchartl | hverkuil: but ENUM_FRAMESIZES can also report a continuous range, shouldn't that be accepted, to give the minimum/maximum output size ? | [17:45] |
| ................................... (idle for 2h54mn) | ||
| tfiga | sailus: isn't it always used for endpoint parsing? | [20:39] |
| sailus | tfiga: Most drivers now parse it without this helper.
It currently has two users left I believe. Time to reboot and to sleep. Have a good night! :-) | [20:53] |
| hverkuil | pinchartl: I thought continuous range was accepted by v4l2-compliance (I may be wrong, I'd have to check) since that effectively gives the min and max scaler sizes. Although that too hasn't been defined explicitly in the API. | [20:57] |
| pinchartl | hverkuil: I may be wrong. libcamera reports discrete values, so that will have to be fixed
but yes, the API doesn't define this | [21:05] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |