[Ffmpeg-devel] Re: [PATCH] mov muxer vfr
Wed Jul 5 11:44:58 CEST 2006
Michael Niedermayer wrote:
> that also means that the track duration is maybe calculated slightly wrong
> correct is the duration = the largest pts (this may or may not be the last
> packet) - the lowest pts (this is likely but not neccesarily the first packet)
> + the duration of the packet with the largest pts
> that should of course be equal to the sum of the durations of all packets
> if the durations are known
> but i dont know if this is what QT expects so maybe the last dts - first
> is less troubblesome for mov ...
I dunno, duration stored in "mdhd" seems to be exactly the sum of all
> 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
> 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.
Should the duration calculation be changed or patch is fine that way ?
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A. http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the ffmpeg-devel