Hi Hans, On Monday 03 August 2009 10:39:03 Hans de Goede wrote: > Hi All, > > The gstreamer folks have asked to add an API to libv4l2 so > that they can distuingish between formats emulated by libv4l2 > and formats offered raw by the hardware. > > I think this is a usefull thing to do and I think this is best > done by adding a new flag for the flags field of the > v4l2_fmtdesc struct. So I would like to propose to add the > following new flag to videodev2.h : > > #define V4L2_FMT_FLAG_EMULATED 0x0002 > > And add the necessary documentation to the spec. The emulated term > is what I've always been using in libv4l discussions for formats > which are not offered native by the hardware but are offered by > libv4l through conversion. If someone has a better name for the > flag suggestions are welcome. I'd go one step further and add a integer cost value instead of a flag. The purpose of distinguishes between native and emulated formats is to keep the end-to-end video cost (in terms of memory, CPU time, ...) as low as possible. If we later end up chaining several conversions in a row (JPEG -> YUV -> RGB for instance, although that might be a bad example) a cost value will help applications select the best format depending on their needs and capabilities. For instance, imagine we "emulate" YUV with a quite low cost and RGB with a quite high cost. If the application can use both YUV and RGB (let's say for display purpose) with equal costs, it will still want to select YUV. Now, the million dollar question is, how do we evaluate the cost value incurred by a software conversion algorithm ? > If you read this and even if your only thoughts are: seems ok to me, > please reply saying so. It is very frustrating to suggest API additions > and not get any feedback. Indeed. I'll remember that comment next time I send an RFC to linux-media and I'll of course expect you to answer ;-) Regards, Laurent Pinchart -- 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
