[FFmpeg-devel] [PATCH] ffmpeg.c : do not reset frame size after encoding small last frame

[Justin Ruggles]

Michael Niedermayer wrote:
> On Wed, Apr 15, 2009 at 11:11:35PM -0400, Justin Ruggles wrote:
>> Hi,
>>
>> 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.

-Justin