Quoting Philip Langdale (2020-04-14 04:48:19) > Previously, there was no way to flush an encoder such that after > draining, the encoder could be used again. We generally suggested > that clients teardown and replace the encoder instance in these > situations. However, for at least some hardware encoders, the cost of > this tear down/replace cycle is very high, which can get in the way of > some use-cases - for example: segmented encoding with nvenc. > > To help address that use case, we added support for calling > avcodec_flush_buffers() to nvenc and things worked in practice, > although it was not clearly documented as to whether this should work > or not. There was only one previous example of an encoder implementing > the flush callback (audiotoolboxenc) and it's unclear if that was > untentional or not. However, it was clear that calling > avocdec_flush_buffers() on any other encoder would leave the encoder in > an undefined state, and 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> > --- > doc/APIchanges | 6 ++++++ > libavcodec/audiotoolboxenc.c | 3 ++- > libavcodec/avcodec.h | 25 ++++++++++++++++++++----- > libavcodec/decode.c | 15 +++++++++++++++ > libavcodec/nvenc_h264.c | 6 ++++-- > libavcodec/nvenc_hevc.c | 6 ++++-- > libavcodec/version.h | 4 ++-- > 7 files changed, 53 insertions(+), 12 deletions(-)
Looks good, no more objections from me. -- Anton Khirnov _______________________________________________ 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".
