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
ndufresne: I don't understand why qvidcap is working with my fix, but not qv4l2. Are you sure you tested qv4l2 correctly?
tfiga: ping
hverkuil: pong
tfiga: pung
hverkuil: uhm, pang? ;)
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)
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
Good to hear you're well again.
So I can expect something this month?
yeah, trying to push things a bit now
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
ndufresne: to be honest I'm not sure cedrus gets the media topology registration right
ndufresne: there are two DMA engines (source + sink) and one encoder/decoder processing block. Hence three entities.
might make sense HW whise, but this is uAPI
it points to the same /dev/videoX node
The MC models the HW. And frankly even from uAPI perspective the capture and output queues are completely independent.
"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
In any case, I remember discussing how to model this in the MC at the time, and this was the solution.
Is there any better rationale documented ?
What exactly is your problem with it? What does it make difficult?
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
I've never used the MC to detect this. Look in v4l2-ctl, v4l2-ctl-streaming.cpp, get_codec_type().
I can check again, what I saw was pretty weak
determine_codec_mask() in v4l2-compliance.cpp is more extensive, but serves the same purpose.
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
True.
(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 ?
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.
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
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.
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
ndufresne: mripard proposed this some months ago ;)
:-)
I know, had a relatively cold reponse
paulk-leonov: this never happened.
mripard: ^_^
there's no i in denial.
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 ?
ndufresne: I *think* I did, but I am not 100% certain.
I'll dig this up a little, I'm sure ezequielg can help
Hmm, I don't see a test for that.
Should be easy enough to implement.
ndufresne: It looks like you are right, and the wrong pads are used in the links to/from the codec processing block.
i have my head deep down in bring up mode.
hverkuil: ah, thanks for confirming, pretty hard to browse the topology when the links are reverted
And if I add a test, it actually fails on this.
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
oh, too bad.
if you push the test, i'll fix the driver hverkuil
ezequielg: pushed test, will also post fixes for v4l2-mem2mem.c and additional checks for this in mc-entity.c.
thanks!
and ndufresne thanks for the vigilance
ndufresne: OK if I add a 'Reported-by' with your name for the kernel fix?
hverkuil: sure, appreciated
hverkuil: thanks for the fixes.
hverkuil: apparently hantro does not use that helper
ndufresne: just sent the fix
ndufresne: see b1c6cc64dd140df8
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
ndufresne: yeah, at least at the driver level.