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

Ronald S. Bultje rsbultje at gmail.com
Tue Feb 16 15:31:34 CET 2016


Hi,

On Tue, Feb 16, 2016 at 8:25 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 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.
>

Hold on a minute, these aren't remotely the same. The slice-thread or
frame-thread flags indicate that the decoder supports a form of MT, and has
significant effect on how the decoder is invoked. These flags are not
informational-only. There's other flags that are not information-only also.
Please distinguish between them.


> The capability flags are there to make things simpler.
>

No.

This is really important: no.

The capability flags are to indicate capabilities of the codec such that
common code (inside ffmpeg!) can invoke the decoder functions correctly and
most optimally. Calling a single-threaded-only decoder with MT will cause
corrupt decoding and crashes. That's bad. Likewise, invoking
single-threaded decoding on a MT decoder will cause a significant slowdown.
Also bad.

The hwaccel flag is informational. The actual capability is checked by
existence of the ACHWAccel with that particular codec id. These info-only
flags can easily be forgotten or be misinterpreted. The AVHWAccel check I
indicated to you is more complete, more informational and guaranteed to be
correct for the particular target platform you're on.

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

So your CPU is from the mid-60s? I mean, you can do that in 1/100th of the
time it takes to decode one block in a modern video codec. And that's an
issue for initialization code why exactly?

Ronald


More information about the ffmpeg-devel mailing list