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

[Philip Langdale]

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.

--phil