On 1/30/2019 2:19 PM, Nicolas George wrote: > James Almer (12019-01-30): >> compat_decode_consumed doesn't look to have any significance when using >> the new API. It's working as an accumulator for all bytes consumed from >> all frames and it's never cleared (sounds like a potential overflow for >> that matter in long lasting decoding scenarios like streaming), whereas >> for the old API it's effectively keeping track of bytes consumed in one >> frame, and cleared after every avcodec_decode_* call. So I guess that's >> why you're clearing it here even though this function should by no means >> do that. >> >> Clearing compat_decode_consumed for the new API should be done somewhere >> in decode.c where it doesn't break the logic for the old API, regardless >> of using the AVCodec.decode() or AVCodec.receive_frame() callbacks. > > I have reservations about adding an API to query something that is > considered deprecated. > > Regards,
I also don't think this is too good of an idea. The new API always consumes and takes ownership of the full packet when you feed it to avcodec_send_packet(), even if it ends up splitting it internally in order to return more than one frame, so in theory just keeping track of what you feed to it in your own code is enough, regardless of how many frames avcodec_receive_frame() gives you back. What this function would do for some decoders however is giving the API user knowledge of said internal splitting after each avcodec_receive_frame() call (an example being VP9). If that's useful or not for the user, i don't know. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
