On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote:
> Thanks,
> Vaibhav Hiremath
>
> > > APPROACH 3 -
> > > ----------
> > >
> > > .....
> > >
> > > (Any other approach which I could not think of would be
> >
> > appreciated)
> >
> > > I would prefer second approach, since this will provide standard
> > > interface to applications independent on underneath hardware.
> > >
> > > There may be many number of such configuration parameters required
> >
> > for
> >
> > > different such devices, we need to work on this and come up with
> >
> > some
> >
> > > standard capability fields covering most of available devices.
> > >
> > > Does anybody have some other opinions on this?
> > > Any suggestions will be helpful here,
> >
> > FYI: I have very little time to look at this for the next 2-3 weeks.
> > As you
> > know I'm working on the last pieces of the v4l2_subdev conversion
> > for 2.6.30
> > that should be finished this week. After that I'm attending the
> > Embedded
> > Linux Conference in San Francisco.
> >
> > But I always thought that something like this would be just a
> > regular video
> > device that can do both 'output' and 'capture'. For a resizer I
> > would
> > expect that you set the 'output' size (the size of your source
> > image) and
> > the 'capture' size (the size of the resized image), then just send
> > the
> > frames to the device (== resizer) and get them back on the capture
> > side.
>
> [Hiremath, Vaibhav] Yes, it is possible to do that.
>
> Hans,
>
> I went through the link referred by Sergio and I think we should inherit
> some implementation for CODECs here for such devices.
>
> V4L2_BUF_TYPE_CODECIN - To access the input format.
> V4L2_BUF_TYPE_CODECOUT - To access the output format.
>
> It makes sense, since such memory-to-memory devices will mostly being
> used from codecs context. And this would be more clear from user
> application.
I haven't had the time to look at this yet.
> And as acknowledged by you, we can use VIDIOC_S_FMT for setting
> parameters.
>
> One thing I am not able to convince myself is that, using "priv" field
> for custom configuration. I would prefer and recommend capability based
> interface, where application will query the capability of the device for
> luma enhancement, filter coefficients (number of coeff and depth),
> interpolation type, etc...
These things are always hard to do since the capabilities are so hardware
dependent. You either end up with a controls-like API (where you basically
can enumerate the capabilities), or you go for a split API: part is for
common functionality, and another part is purely device specific.
> This way we can make sure that, any such future devices can be adapted by
> this framework.
>
>
>
> Hans,
> Have you get a chance to look at Video-Buf layer issues I mentioned in
> original draft?
No, but videobuf is more Mauro's expertise.
As I said, I will have very little time to really look into this until some
2-3 weeks from now :-(
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
