Re: [PATCH v8 28/36] media: subdev: Add [GS]_ROUTING subdev ioctls and operations

[Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>]

Hi,

On 05/10/2021 13:19, Dafna Hirschfeld wrote:
> 
> 
> On 04.10.21 07:15, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 03/10/2021 22:52, Dafna Hirschfeld wrote:
>>
>>>> +/**
>>>> + * struct v4l2_subdev_route - A route inside a subdev
>>>> + *
>>>> + * @sink_pad: the sink pad index
>>>> + * @sink_stream: the sink stream identifier
>>>> + * @source_pad: the source pad index
>>>> + * @source_stream: the source stream identifier
>>>> + * @flags: route flags V4L2_SUBDEV_ROUTE_FL_*
>>>> + * @reserved: drivers and applications must zero this array
>>>> + */
>>>> +struct v4l2_subdev_route {
>>>> +    __u32 sink_pad;
>>>> +    __u32 sink_stream;
>>>> +    __u32 source_pad;
>>>> +    __u32 source_stream;
>>>> +    __u32 flags;
>>>> +    __u32 reserved[5];
>>>> +};
>>>> +
>>>
>>> I don't understand that struct, what is the meaning of the two 
>>> sink_stream, source_stream fields?
>>> What is the relation between sink_pad and source_pad? A 'route' 
>>> between two pads means that 'streams' can flow through them?
>>>
>>> If I have for example:
>>>
>>> sink_pad = sink_stream = 0
>>> source_pad = source_stream = 1
>>>
>>> what does that mean?
>>
>> It means that a stream with stream ID 0 that comes to the subdev's 
>> sink pad 0 will be routed to the subdev's source pad 1 with stream ID 1.
>>
>> So the sink_pad and source_pad tell via which pads the streams flows.
>>
>> Stream IDs are numbers used to uniquely identify the stream for the 
>> specific pad. In other words, for the subdev's pad 0, each stream ID 
>> must be unique. That pad 0 is linked (media link) to another subdev's 
>> pad, and on that pad there must be streams with the matching IDs.

Btw, I've just sent v9 of the series, which includes documentation that 
covers this.

> Ok, so the stream ID for the same stream changes from link to link.

Not necessarily, but yes, it may.

> So different streams can have the same ID on different pads?

True.

> Won't it be more simple if the stream ID is forced to stay the same 
> along all the links and pads?

I don't think so.

For one, it would be difficult, or at least laborious, to verify that 
the above holds true.

Also, streams can appear and disappear, e.g. a single stream in a 
subdev's input side might be split or duplicated into multiple streams 
on the output side.

And I think that it makes sense that e.g. a sensor that outputs two 
streams (pixel & metadata) can have a hardcoded routing, with pad 0 and 
streams 0 and 1. Stream 0 is always the pixel data, and stream 1 is 
always the metadata, and the user knows this so he can connect those 
streams appropriately. If you have multiple cameras, such a scheme would 
not be possible.

What would be the benefit of such rule? Afaik, it would be just for the 
benefit of the human who writes the configuration for the pipeline. And 
with the current series, nothing prevents the user from assigning 
"unique" stream IDs for the pipeline being configured. You can pick 
stream ID 6001 for pixel stream from camera 1, and keep that stream ID 
for the whole pipeline for that stream (assuming the stream won't be split).

That said, I agree that "stream ID" kind of sounds like something used 
to identify the stream, regardless where in the pipeline we look. But 
that is not the case. As I write in the docs: "A stream ID (often just 
"stream") is a media link-local identifier for a stream".

  Tomi