[libcamera-devel] [PATCH] libcamera: pipeline: simple: Support output size ranges

[Dorota Czaplejewicz]

Hi,

I think I know how to solve this, and I've been working on it today.

There's an open question that Benjamin posed: what's the policy for choosing size adjustments?
I think at this stage, that question is best answered by choosing an arbitrary policy and dedicating the effort to get this to work at all. Then to thinking about exposing new APIs.

Now, i have immediate questions about the convertor setup, before I submit my take on the same patch.

> I'm having a hard time to grasp if the core requirements are being met
> though.
> 
> We have two devices that could be configured in 3 different ways:
> 
> 1)
>   ┌────────────┐
>   │   video_   ├──► Stream0
>   └────────────┘
> 
> 2)
>   ┌────────────┐   ┌────────────┐
>   │   video_   ├──►│ convertor_ ├──►  Stream0
>   └────────────┘   └────────────┘
> 
> 3)
>   ┌────────────┐   ┌────────────┐
>   │   video_   ├──►│ convertor_ ├──►  Stream1
>   └───────┬────┘   └────────────┘
>           │
>           └► stream0
> 

Is this last picture really correct? I was under the impression that the sensor is expected to create only one stream, and all extra streams are handled by the converter.
A comment in camera.cpp says:

> * It is possible to produce up to one stream without conversion

There's also the question about how independent the different streams can be. It's undocumented, but SimpleCameraData::Configuration seems to define the range of configurations which can be simultaneously deployed on multiple streams.

```
struct Configuration {
	...
	std::vector<PixelFormat> outputFormats;
	SizeRange outputSizes;
}
```

Reading through the validate() code, any combination of those will be accepted, no matter how many streams.

Is that the intended function of this structure?

Originally I was under an impression that it merely enumerated supported modes, and that replacing the outputFormats collection with multiple Configurations, each with a single outputFormat would not change any functionality. But now I think this is actually overloaded with converter configuration.

I don't want to mess up the structuring of this code, so I'm going to hold on until I get an answer to this question.

Thanks,
Dorota
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20211217/0872efe2/attachment.sig>