Re: [PATCH 12/13] media: v4l2-mc: Introduce v4l2_mc_pipeline_enabled()

[Sakari Ailus <sakari.ailus@linux.intel.com>]

Hi Laurent,

On Tue, Jul 15, 2025 at 02:25:20PM +0300, Laurent Pinchart wrote:
> On Tue, Jul 15, 2025 at 10:49:32AM +0000, Sakari Ailus wrote:
> > On Fri, Jun 20, 2025 at 10:53:13AM +0200, Jacopo Mondi wrote:
> > > On Thu, Jun 19, 2025 at 11:15:45AM +0300, Sakari Ailus wrote:
> > > > v4l2_mc_pipeline_enabled() helps solving a problem known for long but
> > > > lacked any sort of general solution: with multiple streams, when streaming
> > > > is started on video nodes one by one, when should streaming be started in
> > > > the source?
> > > 
> > > I tried quite some time to understand this, but if I'm not mistaken,
> > > a stream-aware subdev, which links to vdev, will always "demux"
> > > streams to different pads and will connect to the vdev from there
> > > 
> > > 
> > >      Source
> > >      subdev
> > >  +-----------------+
> > >  |                (1/0) ------> vdev0
> > >  |                 |
> > > (0)[1,2,3]        (2/0  ------> vdev1
> > >  |                 |
> > >  |                (3/0) ------> vdev2
> > >  +-----------------+
> > > 
> > > With
> > > 
> > > (0) multiplexed sink pad with 3 streams
> > > (1) (2) and (3) source pad with a single stream
> > > 
> > > Can't we relay on the media-link state between the source pads and the
> > > video devices with something like what Dan has proposed here ?
> > > https://patchwork.linuxtv.org/project/linux-media/patch/20250519140403.443915-2-dan.scally@ideasonboard.com/
> > 
> > This isn't entirely the same thing: pipeline is specific to the pad but not
> > streams, ad here we're interested in streams. Two streams may start at
> > different points of time even if both are part of the same pipeline.
> > 
> > We definitely should have just one way to figure this out.
> 
> But can we ? Isn't it dependent on use cases ? I can imagine an
> application wanting to capture two image streams where one of them is
> enabled all the time and the other one is regularly turned on and off,
> in which case you would need to start the pipeline when the first stream
> starts. A different application may instead want to capture the same two
> streams and make sure it gets all frames on both, which possibly
> requires delaying the start of capture until both video capture devices
> are started.

Exactly. It's indeed dependent on the use case but the driver is the same
in both cases. This is why the generic solution needs more information from
the user space but I think we can work out how to support this after
merging the metadata series.

-- 
Regards,

Sakari Ailus