On Mon, 13 Apr 2020 at 04:39, Anton Khirnov <an...@khirnov.net> wrote: > > Quoting Philip Langdale (2020-04-11 01:47:43) > > We've been in this fuzzy situation where maybe you could call > > avcodec_flush_buffers() on an encoder but there weren't any encoders > > that supported it except maybe audiotoolboxenc. Then we added flush > > support to nvenc very intentionally, and it worked, but that was more a > > coincidence than anything else. And if you call avcodec_flush_buffers() > > on an encoder that doesn't support it, it'll leave the encoder in an > > undefined state, so that's not great. > > > > As part of cleaning this up, this change introduces a formal capability > > flag for encoders that support flushing and ensures a flush call is a > > no-op for any other encoder. This allows client code to check if it is > > meaningful to call flush on an encoder before actually doing it. > > > > I have not attempted to separate the steps taken inside > > avcodec_flush_buffers() because it's not doing anything that's wrong > > for an encoder. But I did add a sanity check to reject attempts to > > flush a frame threaded encoder because I couldn't wrap my head around > > whether that code path was actually safe or not. As this combination > > doesn't exist today, we'll deal with it if it ever comes up. > > > > Signed-off-by: Philip Langdale <phil...@overt.org> > > --- > > I'm missing two things here: > - motivation in the commit message (and possibly in the doxy too) - why > is this needed and how is it better than just closing the encoder and > creating a new one
One use case is segmented encoding: processing one segment at a time, where closing and re-opening a new encoder is expensive (as is the case with HW / nvenc). The original writeup for the motivation leading up to "encoder flush" can be found here: https://patchwork.ffmpeg.org/project/ffmpeg/patch/1574125994-7782-1-git-send-email-joshua.allm...@gmail.com/ Josh _______________________________________________ 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".