Andreas Rheinhardt (12020-09-10): > The movie and amovie filters currently use two packets. One of the two, > pkt0, is the owner of the returned packet; it is also the destination > packet for av_read_frame(). The other one pkt is initially (i.e. after > av_read_frame()) a copy of pkt0; copy means that the contents of both > are absolutely the same: They both point to the same AVBufferRef and the > same side data. This violation of the refcounted packet API is only > possible because pkt is not considered to own its data. Only pkt0 is > ever unreferenced. > The reason for pkt's existence seems to be historic: > The API used for decoding audio (namely avcodec_decode_audio4()) could > consume frames partially, i.e. it could return multiple frames for one > packet and therefore it returned how much of the input buffer had been > consumed. The caller was then supposed to update the packet's data and > size pointer to reflect this and call avcodec_decode_audio4() again with > the updated packet to get the next frame. > But before the introduction of refcounted AVPackets where knowledge and > responsibility about what to free lies with the underlying AVBuffer such > a procedure required a spare packet (or one would need to record the > original data and size fields separately to restore them before freeing > the packet; notice that this code has been written when AVPackets still > had a destruct field). But these times are long gone, so just remove the > secondary AVPacket. > > Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@gmail.com> > --- > It seems that the avcodec_decode_audio4() lost the ability to output > multiple frames per packet in 061a0c14bb5767bca72e3a7227ca400de439ba09. > Am I right?
I think I am ok with the change (and the two others), but I think it would be much more useful update src_movie to use the new decoding API: no need to keep a packet in the context, no need to distinguish between audio and video. More work, but more useful. And it would allow to properly implement an activate version. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ 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".