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

Michael Niedermayer michaelni
Wed Jul 5 22:25:24 CEST 2006


Hi

On Wed, Jul 05, 2006 at 02:31:29PM +0200, Baptiste Coudurier wrote:
[...]
> 
> > 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.

what you say makes only sense for PCM, for others it doesnt make sense
and they are what iam curious about ...

so with "48000, 1" you mean QT handles 1 single packet which when decoded
would produce 48000 samples as if the packet actually could be split into
48000 decodable pieces of duration 1?
now iam curious what byte sizes QT wants for these non existant 48000
samples?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is




More information about the ffmpeg-devel mailing list