[FFmpeg-devel] [PATCH] ffmpeg.c : do not reset frame size after encoding small last frame
Thu Apr 16 06:26:31 CEST 2009
Michael Niedermayer wrote:
> On Wed, Apr 15, 2009 at 11:11:35PM -0400, Justin Ruggles wrote:
>> This patch removes the save/restore of the previous enc->frame_size
>> before and after writing a small last frame.
>> This makes the value correct when writing the last packet. The muxer
>> should not assume this value to be constant during encoding, so should
>> not use it if rewriting the header during write_trailer(). The FLAC
>> muxer did this, but I fixed it earlier today.
>> As a result, the recent addition by Baptiste to calculate the packet
>> duration for the small last frame is not needed since it will be
>> correctly calculated by lavf if enc->frame_size is correct.
> iam not in favor of this patch, frame_size is the only means by which a
> muxer knows the size of frames (except the last) if it is constant.
> making this value unreliable would mean odd bugs and muxers requireing to
> cache its value at the begin.
> AVPacket.duration is the one and correct place to indicate the current
> packets duration, a value in the context is not a good choice, packets
> can be buffered at many places, the stream interleaving code is just
> one and given that the value written in there by the app(ffmpeg) may
> not match the packet the demuxer is actually writing next
Ok, I see your point. The only muxer I could find that uses current
AVCodecContext.frame_size to mean the number of samples in the current
packet is swf, and it only supports mp3 which has a constant frame size.
Ideally, there would be some other way of telling an encoder how many
samples to encode so that we don't have to use that hack to encode a
smaller frame. It would also eliminate the need to have different
parameter meanings in avcodec_encode_audio() for PCM vs. other audio codecs.
More information about the ffmpeg-devel