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

[Ali KIZIL]

Marton Balint <cus at passwd.hu>, 9 Nis 2020 Per, 01:23 tarihinde şunu yazdı:

>
>
> 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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".


Does this patch offer any solution to ticket
https://trac.ffmpeg.org/ticket/8225  ?