> 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.
Seems fine to me. I can't think of any objections.
As an aside: perhaps it is a good idea to start documenting the libv4l in
the spec as well.
>
> 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 ?
I don't think we should attempt to do things like this. I don't believe
there is a need for it, and even if there is, then we really have no idea
on how to represent such a cost. Having an emulated flag makes a lot of
sense, but attempting to go any further with this seems premature at the
least.
Regards,
Hans
>
>> 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
>
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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
