Hello, On Tuesday, October 06, 2009 6:12 PM Hiremath, Vaibhav wrote:
> > 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? Currently, it looks that all issues are resolved. However, something might arise during the implementation. If so, I will post it here of course. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
