On 3/10/2020 4:08 PM, Anton Khirnov wrote: > Quoting James Almer (2020-03-10 19:14:47) >> On 3/10/2020 3:03 PM, Anton Khirnov wrote: >>> Quoting James Almer (2020-02-27 19:01:59) >>>> It's not a decoding exclusive function. >>> >>> How come? The doxy for it says >>> 'Reset the internal decoder state / flush internal buffers.' >> >> It touches some fields used by encode.c, like draining and >> buffer_pkt_valid (the latter which admittedly will be gone after this >> patchset, but replaced by others), > > draining is for decoders too I think > >> and there's at least one encoder implementing an AVCodec.flush() >> callback. >> >> And doesn't the slash in that doxy imply one or the other? > > Hmm, apparently I wrote that doxy and have no recollection of it :) > I think it was supposed to be decoding only.
I made the question because i interpreted it as such, and seeing encoders adding flush callbacks, the same might have done others. It wasn't the correct interpretation, so good to know. > > I see two encoders implementing flush: audiotoolbox and nvenc. The > addition to nvenc was explicit, but not even a year old, audiotoolbox > might or might not have been deliberate. > > So it seems pretty unclear to me. I would say calling it on an encoder > is invalid and undefined, but apparently people are doing that and it > sort of sometimes works. I can withdraw this patch (And remove the relevant chunks from the following two) if this function was effectively not meant for encoders. Also maybe poke Timo regarding nvenc flushing, to see why it is needed and if there's an alternative. _______________________________________________ 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".