On Sun, 25 Jun 2017 12:43:12 +0100 Mark Thompson <s...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
