On Sun, 25 Jun 2017 14:27:06 -0700 Philip Langdale <phil...@overt.org> wrote:
> Dummy hwaccels, of which cuvid is the best example, behave differently > from real hwaccels. In the past, one of these behaviours was that > selecting the hwaccel would automatically cause the decoder (and > remember it's a dedicated decoder) to use the native hardware output > format. > > This meant that transcoding command lines would pass frames through > device memory automatically once the right hwaccel and decoder/encoder > were selected. > > With the generic hwaccel code path, dummy decoders end up following > the 'real' hwaccel path where the output format defaults to a software > format. > > To avoid users facing an unexpected change in behaviour, we now > indicate whether an hwaccel is a dummy, and if it is, we set the > default output format appropriately. > > To make this process easier, I updated ffmpeg to pass the HWAccel > struct to the init() call so that we know which decoder we are > dealing with. > > Signed-off-by: Philip Langdale <phil...@overt.org> > --- Doesn't this still mean hwaccels will push sw frames to filters, but cuvid pushes hw frames? I thought we were trying to get rid of this inconsistency? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
