[FFmpeg-devel] [PATCH] avcodec/nvenc: adapt to the new internal encode API

Marton Balint cus at passwd.hu
Thu Apr 9 01:23:28 EEST 2020



On Wed, 8 Apr 2020, Philip Langdale wrote:

> On Wed,  8 Apr 2020 14:58:36 -0300
> James Almer <jamrial at gmail.com> wrote:
>
>> Signed-off-by: James Almer <jamrial at gmail.com>
>> ---
>> This removes the encode2() implementation as it'll never be used if a
>> receive_packet() one exists, and the flush() implementation since
>> according to Anton Khirnov avcodec_flush_buffers() is not meant to be
>> used with encoders, where its behavior is undefined.
>
> Nevertheless, there is a use case for flushing an encoder (see 3ea705),
> and when you call avcodec_flush_buffers() in nvenc, it does the right
> thing.
>
> Removing this will return us to the world before that change where
> there was no way to flush the encoder, and the original bug reporter
> was asking about adding an API to do it.
>
> It seems the right thing to do is to define the behaviour - which seems
> reasonable as-is today and documment that encoders can implement flush
> if necessary. Or we'll just end up adding a new API that flushes
> encoders but has a different name...

I guess the problem is that avcodec_flush_buffers() does not return a 
result so it can't signal if it is implemented by the encoder, therefore 
the application will not know if avcodec_flush_buffers() is enough or it 
has to create a new encode context. Maybe a capability flag can be added 
to signal support, but a different function might just be cleaner...

Regards,
Marton


More information about the ffmpeg-devel mailing list