On 4/8/2020 7:04 PM, 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... > > --phil
I'm not against it, but as Marton said the function as it is is not enough. The changes Anton asked me to remove would need to be re-added (trivial to do), and the threading related code would probably need some changes, if anything to not call decoding specific functions on an encoder context. I like the codec capabilities suggestion from Marton. Could you look into it? I'll change this patch to not remove the flush call while at it. _______________________________________________ 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".
