> -----Original Message----- > From: Ivan T. Ivanov [mailto:iivanov@xxxxxxxxxx] > Sent: Tuesday, October 06, 2009 12:27 AM > To: Hiremath, Vaibhav > Cc: Marek Szyprowski; linux-media@xxxxxxxxxxxxxxx; > kyungmin.park@xxxxxxxxxxx; Tomasz Fujak; Pawel Osciak > Subject: RE: Mem2Mem V4L2 devices [RFC] > > <snip> > > > > > last thing which should be done is to QBUF 2 buffers and > call > > > > > STREAMON. > > > > > > > > > [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. > > > > App1 App2 App3 ... AppN > > | | | | | > > ----------------------------------------------- > > | > > /dev/video0 > > | > > Resizer Driver > > why not? they can be per file handler input/output queue. and we > can do time sharing use of resizer driver like Marek suggests. > [Hiremath, Vaibhav] Ivan, File handle based queue and buffer type based queue are two different terms. Yes, definitely we have to create separate queues for each file handle to support multiple channels. But my question was for buffer type, CAPTURE and OUTPUT. Thanks, Vaibhav > > > > > 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 > > > > Every application will start streaming with (mostly) fixed scaling > factor which mostly never changes. This one video node approach is > possible only with constraint that, the application will always > queue only 2 buffers with one CAPTURE and one with OUTPUT type. > > i don't see how 2 device node approach can help with this case. > even in "normal" video capture device you should stop streaming > when change buffer sizes. > > > He has to wait till first/second gets finished, you can't queue > multiple buffers (input and output) simultaneously. > > actually this should be possible. > > iivanov > > > > > I do agree here with you that we need to investigate on whether we > really have such use-case. Does it make sense to put such constraint > on application? What is the impact? Again in case of down-scaling, > application may want to use same buffer as input, which is easily > possible with single node approach. > > > > Thanks, > > Vaibhav > > > > > > We have to put some constraints - > > > > > > > > - Driver will treat index 0 as input always, > irrespective of > > > number of buffers queued. > > > > - Or, application should not queue more that 2 buffers. > > > > - Multi-channel use-case???? > > > > > > > > I think we have to have 2 device nodes which are capable of > > > streaming multiple buffers, both are > > > > queuing the buffers. > > > > > > In one video node approach there can be 2 buffer queues in one > video > > > node, for input and output respectively. > > > > > > > The constraint would be the buffers must be mapped one-to-one. > > > > > > Right, each queued input buffer must have corresponding output > > > buffer. > > > > > > 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
