If we have camera here as a distinct object, should its setup be passed as a graph compile arg?

Actually, when the graph is compiled there's no idea whether a file or a camera will be used as input.

I'd leave it as is for now. Non-camera input will be introduced later in a separate PR

MediaFrame has these enums already,

There are more color formats supported by OAK, should we stick to BGR and NV12 only?

we should extend MediaFrame enums then. :)

Change to cv::MediaFormat

but finally it looks here as intended :)

why do you need this in every kernel?

Some of the DAI operations need to set max resolution size

but why still not to move oak_frame by itself?

What about VectorRef case below? I think we should be consistent here

could you describe what is VectorRef case (why we introduced it here) and why MediaFrame is not enough?

We use VectorRef for encoding - it's operation's output. VectorRef is basically a vector while MediaFrame is more flexible type. This logic could also be extended in the future for other types like cv::Mat, Opaque, etc

And here you can look at d->inNodes() (should be only one producer)

could you describe what is VectorRef case (why we introduced it here) and why MediaFrame is not enough?

Stride is a distance between every row in a plane, in bytes.
If passing width looks legit here for Y plane, how height could become a stride for UV plane?

⚠ @sivanov-work @rgarnov am I wrong here?

That worked somehow, but you're right. Changed to width and width for both planes

Its debatable but so far OAKMediaAdapter itself may be private so no extra PIMPLing required.

there's no strict defined order in out_nodes right?

It's aligned with the backend's out_data and is being used in that aligned way

This search is linear too. Also why do you need this check here at all? Is your inter_nodes incorrect?

Done