[Ffmpeg-devel] Re: [PATCH] mov muxer vfr

[Baptiste Coudurier]

Hi

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
>> else?

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