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

[Michael Niedermayer]

Hi

On Wed, Jul 05, 2006 at 11:44:58AM +0200, Baptiste Coudurier wrote:
[...]
> > furthermore it would be nice if the duration calculation would be done in
> > lavf and not in an individual muxer, so that after all packets have been 
> > passed into av_*write_frame() the AVStream.duration is based on their
> > timestamps instead of some loosy guess
> 
> Indeed, that would be nice. Btw, why is pkt->duration not adjusted the
> way dts are ? It seems more logic to me, to get packets with different
> durations in the muxer. Also I was thinking that when stream copy, pkt
> duration should be copied from input pkt, is it correct ? See attached
> patch.

looks ok


> 
> > and why are some specific audio codecs handled differently? is this needed?
> > 
> > [...]
> > 
> 
> 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?

[...]

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