[FFmpeg-devel] [PATCH 0/2] RFC: Generic hwaccel for cuvid v2

Philip Langdale philipl at overt.org
Sun Jun 25 16:57:45 EEST 2017

On Sun, 25 Jun 2017 12:43:12 +0100
Mark Thompson <sw at jkqxz.net> wrote:

> Point (2) is somewhat more subtle.  The default hwaccel behaviour is
> made for the real hwaccels attached to the normal decoder, and won't
> do the right thing for the dummy ones.  The specific case that we
> strongly want to avoid is some normal setting where the output is
> downloaded to normal memory from a hardware frame inside ffmpeg,
> because that is almost certainly done more efficiently in the decoder
> itself (for the CUVID case, it actually has two explicit copies if
> you do this).  It's rare that you ever want to specify anything other
> than the hardware format or the corresponding software format for
> decode (and in fact I think only VAAPI supports such
> convert-on-download cases anyway), so the single toggle is usually
> sufficient.
> Therefore, I think we should just clearly distinguish between the two
> general behaviours for the hwaccel case - real and dummy.  That's
> essentially what your patch at
> <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-June/212566.html>
> did, but in a slightly implicit way - I would put it in
> hwaccel_decode_init() rather than in the option parsing code.
> There was some question of whether all hwaccels (real and dummy)
> should behave identically here, but given the nasty default case if
> we do that I don't think it's justified (though feel free to argue
> further on this point if you feel strongly, I'm not that attached to
> it).
> TL;DR - I preferred the mechanism of the previous version, with some
> changes to make it clearer what the distinction is.

Makes sense. I'll post an updated diff later today. Thanks for
explaining all your thoughts on this.


More information about the ffmpeg-devel mailing list