[FFmpeg-devel] [PATCH] Do not remove HWACCEL flag with FF_API_XVMC

Hendrik Leppkes h.leppkes at gmail.com
Mon Feb 15 15:22:43 CET 2016


On Mon, Feb 15, 2016 at 3:13 PM, Ivan Kalvachev <ikalvachev at gmail.com> wrote:
> On 2/15/16, Ronald S. Bultje <rsbultje at gmail.com> wrote:
>> Hi,
>>
>> On Mon, Feb 15, 2016 at 8:26 AM, Ivan Kalvachev <ikalvachev at gmail.com>
>> wrote:
>>
>>> On 2/15/16, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
>>> > On Mon, Feb 15, 2016 at 2:13 PM, Ivan Kalvachev <ikalvachev at gmail.com>
>>> > wrote:
>>> >> Do not remove HWACCEL flag with FF_API_XVMC since the
>>> >> flag is supposed to be used as generic one.
>>> >>
>>> >
>>> > The flag is unused except by the XVMC decoder, so removing it with it
>>> > seems appropriate.
>>>
>>> Should I add it to the other hwaccel decoders?
>>
>>
>> Would it have a real-world purpose?
>
> Does any of the other Capability flags serve any real-world purpose?
> e.g. CAP_DRAW_HORIZ_BAND or  CAP_DR1.
>
> The *_BAND indicates usage of draw_horiz_band callback().
> The * _DR1 indicates usage of get_buffer(),

DR1 could probably be removed as well, since practically every codec
we have does it this way now.
But removing existing things and adding new things are entirely
different topics.

> The *_HWACCEL is supposed to indicate usage of get_format() and
> availability of certain data, when it is called.
>
> Since the trend is removing codecs that do only hwaccel,
> I think it is useful for the application to know that the codec
> can do more than software decoding.
>

This is hardly useful, because hwaccels do not "just work", for proper
hwaccel support you need to hardcode the available codecs in your
application and appropriate conditions for them, so things like
profile checks, hardware compatibility checks, etc can be implemented.
A generic "this codec does hwaccel" flag is not very useful here.

- Hendrik


More information about the ffmpeg-devel mailing list