RE: Mem2Mem V4L2 devices [RFC]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: Marek Szyprowski [mailto:m.szyprowski@xxxxxxxxxxx]
> Sent: Tuesday, October 06, 2009 11:53 AM
> To: Hiremath, Vaibhav; 'Ivan T. Ivanov'; linux-media@xxxxxxxxxxxxxxx
> Cc: kyungmin.park@xxxxxxxxxxx; Tomasz Fujak; Pawel Osciak; Marek
> Szyprowski
> Subject: RE: Mem2Mem V4L2 devices [RFC]
> 
> Hello,
> 
> On Monday, October 05, 2009 8:27 PM Hiremath, Vaibhav wrote:
> 
> > > > [Hiremath, Vaibhav] IMO, this implementation is not streaming
> > > model, we are trying to fit mem-to-mem
> > > > forcefully to streaming.
> > >
> > > Why this does not fit streaming? I see no problems with
> streaming
> > > over mem2mem device with only one video node. You just queue
> input
> > > and output buffers (they are distinguished by 'type' parameter)
> on
> > > the same video node.
> > >
> > [Hiremath, Vaibhav] Do we create separate queue of buffers based
> on type? I think we don't.
> 
> Why not? I really see no problems implementing such driver,
> especially if this heavily increases the number of use cases where
> such
> device can be used.
> 
[Hiremath, Vaibhav] I thought of it and you are correct, it should be possible. I was kind of biased and thinking in only one direction. Now I don't see any reason why we should go for 2 device node approach. Earlier I was thinking of 2 device nodes for 2 queues, if it is possible with one device node then I think we should align to single device node approach.

Do you see any issues with it?

Thanks,
Vaibhav

> > App1		App2		App3		...		AppN
> >   |		 |		|		|		  |
> >    -----------------------------------------------
> > 				|
> > 			/dev/video0
> > 				|
> > 			Resizer Driver
> >
> > Everyone will be doing streamon, and in normal use case every
> application must be getting buffers from
> > another module (another driver, codecs, DSP, etc...) in multiple
> streams, 0, 1,2,3,4....N
<snip>
> case in which the operation can be performed in-place. Usually all
> other types of operations (like color space conversion or rotation)
> require 2 buffers. Please note that having only one video node
> would not mean that all operations must be done in-place. As Ivan
> stated you can perfectly queue 2 separate input and output buffers
> into the one video node and the driver can handle this correctly.
> 
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux