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

Ivan Kalvachev ikalvachev at gmail.com
Tue Feb 16 14:25:34 CET 2016


On 2/15/16, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> 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.

That's not correct - *_HWACCEL isn't new thing either.

You do understand that blocking this change means
removing existing thing, don't you?


>> 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.

Yes, it is not mandatory for decoding.

But that's true for all capabilities flag, including the threading ones.
If your application supports threading you can always use the thread
safe functions.

The capability flags are there to make things simpler.

Currently the only way an application could find that given codec
supports hwaccel
is to decode a frame, wait for get_format() callback and check the pixfmt list.

Ronald proposed to implement public function that would
query if given codec support given hwaccel pixfmt.
It's good, but it is not simple.
(Listing decoders is 400+ codecs * 10 hwaccel types,
traversing 40+ element table for each combination.)

It literally cannot be simpler than using the already existing flag.
The bit is already allocated for that, it is kept unused in the new
AV_CODEC_CAP*


Best Regards


More information about the ffmpeg-devel mailing list