On Wed, 8 Apr 2020, Philip Langdale wrote:
On Wed, 8 Apr 2020 14:58:36 -0300
James Almer <jamr...@gmail.com> wrote:
Signed-off-by: James Almer <jamr...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
