[Ffmpeg-devel] Re: [PATCH] mov muxer vfr
Wed Jul 5 14:31:29 CEST 2006
Erik Slagter wrote:
> On wo, 2006-07-05 at 13:42 +0200, Michael Niedermayer wrote:
>>> With lavf api, chunk will contain many raw samples, and so have a long
>>> duration, I could store each chunk duration but, according to quicktime,
>>> CBR audio must have a compressed "stts" of one element, since raw
>>> samples have all a duration of 1. If you don't do that it simply does
>>> not work in quicktime.
>> iam not sure what you are saying here ...
>> do you mean some encoders concatenate multiple packets into a single
>> AVPacket or that
>> Quicktime handles CBR as if each byte would be a packet? or something
Encoders output packets which contains multiple samples (PCM, ADPCM, QDM2).
> Just my $0.02, maybe I'm completely off, but you never know...
> The sample durations (afaik for either audio and video) are encoded
> using some sort of run length encoding (at least with newer .mp4
> versions, don't know for mov). For cbr this would mean the complete
> sample durations list would collapse into a single entry. Apparently
> quicktime doesn't like it when this run length encoding is not
> performed. And from Baptiste's comment I understand this approach is not
> easy to implement in lavf...
Let me get an specific example:
AVPacket contains 48000 sample of raw audio. Since raw sample duration
is 1. AVPacket would have a duration of 48000 (track timescale), but
instead of setting "stts" to 1, 48000, quicktime requires that "stts"
for CBR audio (also QDM2, ADPCM), be set as 48000, 1.
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A. http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
More information about the ffmpeg-devel