| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| ndufresne | mchehab: do I read this patch properly " [media] media-device: map new functions into old types for legacy API
It basically make it impossible to get any function ID using enum entity ? So basically it makes ENUM_ENTITIES deprecated (legacy) without a single work in the documentation ? * single word | [00:13] |
| ........................................................................................ (idle for 7h17mn) | ||
| hverkuil | ndufresne: I don't understand why qvidcap is working with my fix, but not qv4l2. Are you sure you tested qv4l2 correctly? | [07:31] |
| tfiga: ping | [07:38] | |
| ............................... (idle for 2h31mn) | ||
| tfiga | hverkuil: pong | [10:09] |
| ................................. (idle for 2h44mn) | ||
| hverkuil | tfiga: pung | [12:53] |
| tfiga | hverkuil: uhm, pang? ;) | [13:01] |
| hverkuil | I had 'peng' in mind :-)
but pang works too Question: when can you present which areas of the API need improvement based on the feedback you got? It's mainly for planning on my side, since I suspect that once we have that, it is something for which I need to put aside time. I also know that some of the ideas are needed for the Tegra driver that has been posted (non-standard alignment between luma and chroma planes, to be precise) | [13:01] |
| tfiga | hverkuil: I've been out sick for a couple of weeks and it didn't progress too much :(
but we just resumed and the report is being finalized | [13:07] |
| hverkuil | Good to hear you're well again.
So I can expect something this month? | [13:10] |
| tfiga | yeah, trying to push things a bit now | [13:16] |
| ....... (idle for 32mn) | ||
| ndufresne | ezequielg: paulk-leonov: Question about stateless codec topology, why did we decide to add two entities for the same video node ?
With media_v2, which is the only usable API in this case, you can express the same thing with only two entities, and this would be much easier for userspace during HW identitication | [13:48] |
| paulk-leonov | ndufresne: to be honest I'm not sure cedrus gets the media topology registration right | [13:50] |
| hverkuil | ndufresne: there are two DMA engines (source + sink) and one encoder/decoder processing block. Hence three entities. | [13:51] |
| ndufresne | might make sense HW whise, but this is uAPI
it points to the same /dev/videoX node | [13:51] |
| hverkuil | The MC models the HW. And frankly even from uAPI perspective the capture and output queues are completely independent. | [13:52] |
| ndufresne | "completely" is a strong exageration
with stateless codec, you setup your input and output buffers all at the same time, they are far from independant it's like a GPU operation | [13:53] |
| hverkuil | In any case, I remember discussing how to model this in the MC at the time, and this was the solution. | [13:54] |
| ndufresne | Is there any better rationale documented ? | [13:54] |
| hverkuil | What exactly is your problem with it? What does it make difficult? | [13:55] |
| ndufresne | navigating the topology is load of code, the more useless entity, the more work it it to reliable classify a m2m node as being a stateless encoder/decoder
it's also just awkward to me that a device node is mapped to two entities, but that might be just a matter of taste anyway, I can do with it, I don't really like it | [13:56] |
| hverkuil | I've never used the MC to detect this. Look in v4l2-ctl, v4l2-ctl-streaming.cpp, get_codec_type(). | [13:58] |
| ndufresne | I can check again, what I saw was pretty weak | [13:58] |
| hverkuil | determine_codec_mask() in v4l2-compliance.cpp is more extensive, but serves the same purpose. | [13:59] |
| ndufresne | get_codec_type() is the stateful heuristic, and that's pretty weak, the point of the MC is that you can check the function on the proc
you basically you expect m2m video device + DECODER or ENCODER proc we could also accept having a scaler, or scs in the pipeline of course | [13:59] |
| hverkuil | True. | [14:00] |
| ndufresne | (though get_codec_type() as this that it's really simple)
hverkuil: eh, V4L2_FMT_FLAG_COMPRESSED, is this recent addition or was that always present ? | [14:01] |
| hverkuil | Although the heuristic is actually pretty decent since if one side is compressed and the other isn't, then that's a pretty clear sign that it is a codec.
Has always been there. | [14:02] |
| ndufresne | oops, missed it, note that in gst that wasn't sufficient, I needed to differentiate raw, container and compressed
the only container we support is MPEG-TS iirc, I don't think we added IVF in the end hverkuil: you could have a special codec analyses node that spits a motions vectors representation in a raw image, or something | [14:02] |
| hverkuil | I've always thought that the kernel should return a lot more meta information about pixelformats to userspace, so each application doesn't have to keep a table of their own. Unfortunately, I never managed to get enough support for that idea. | [14:04] |
| ndufresne | I think if our dictator was interested, he'd force having a single central set of pixel/media formats ;-D
(just kidding) but a central place would sanitize the Linux uAPI in this regard good luck getting all maintainers to agree on an interface though | [14:05] |
| paulk-leonov | ndufresne: mripard proposed this some months ago ;) | [14:06] |
| hverkuil | :-) | [14:06] |
| ndufresne | I know, had a relatively cold reponse | [14:06] |
| .... (idle for 17mn) | ||
| mripard | paulk-leonov: this never happened. | [14:23] |
| ................ (idle for 1h18mn) | ||
| ezequielg | mripard: ^_^
there's no i in denial. | [15:41] |
| .............. (idle for 1h9mn) | ||
| ndufresne | ezequielg: did we carefully checked all the topology ? I got a link with source_id pointing to a sink pad
hverkuil: do you validate this in compliance ? | [16:50] |
| *** | benjiG has left | [16:55] |
| ...... (idle for 27mn) | ||
| hverkuil | ndufresne: I *think* I did, but I am not 100% certain. | [17:22] |
| ndufresne | I'll dig this up a little, I'm sure ezequielg can help | [17:23] |
| hverkuil | Hmm, I don't see a test for that.
Should be easy enough to implement. | [17:23] |
| ndufresne: It looks like you are right, and the wrong pads are used in the links to/from the codec processing block. | [17:35] | |
| ezequielg | i have my head deep down in bring up mode. | [17:35] |
| ndufresne | hverkuil: ah, thanks for confirming, pretty hard to browse the topology when the links are reverted | [17:37] |
| hverkuil | And if I add a test, it actually fails on this. | [17:37] |
| ndufresne | I think it's fair to add a test ;-D
I'm actually surprise it's not validated by the kernel, we can't trust drivers ;-D | [17:38] |
| ezequielg | oh, too bad.
if you push the test, i'll fix the driver hverkuil | [17:40] |
| ..... (idle for 21mn) | ||
| hverkuil | ezequielg: pushed test, will also post fixes for v4l2-mem2mem.c and additional checks for this in mc-entity.c. | [18:01] |
| ezequielg | thanks!
and ndufresne thanks for the vigilance | [18:04] |
| hverkuil | ndufresne: OK if I add a 'Reported-by' with your name for the kernel fix? | [18:07] |
| ............ (idle for 55mn) | ||
| ndufresne | hverkuil: sure, appreciated | [19:02] |
| ....... (idle for 32mn) | ||
| ezequielg | hverkuil: thanks for the fixes. | [19:34] |
| ndufresne | hverkuil: apparently hantro does not use that helper | [19:36] |
| ezequielg | ndufresne: just sent the fix
ndufresne: see b1c6cc64dd140df8 | [19:37] |
| ndufresne | ezequielg: hverkuil: I've commented, I think code whise, we need to add local defines, to make this humanly possible to identify such bug, 0 and 1 are just magic number | [19:39] |
| ezequielg | ndufresne: yeah, at least at the driver level. | [19:46] |
| ndufresne | ndufresne rebooted for no reason, hantro is a module | [19:55] |
| ............. (idle for 1h2mn) | ||
| ndufresne pretty glad this topology query code is done | [20:57] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |