[Ffmpeg-devel] compute_frame_duration and pkt->duration

[Michael Niedermayer]

Hi

On Wed, Nov 15, 2006 at 11:04:01AM +0100, Baptiste Coudurier wrote:
> Hi
> 
> Michael Niedermayer wrote:
> > Hi
> > 
> > On Wed, Nov 15, 2006 at 01:07:09AM +0100, Baptiste Coudurier wrote:
> >> Baptiste Coudurier wrote:
> >>> Hi
> >>>
> >>> Here is the problem I experience:
> >>>
> >>> gxfenc.c av_set_pts_info to 1/50 because gxf dts are field based, while
> >>> codec timebase is 1/25. When computing frame duration, it first takes
> >>> stream timebase, and it will compute frame duration as 1, and timebase
> >>> as 1/50.
> >>>
> >>> With delay, that will cause first dts to be -1 in stream timebase.
> >>> dts in gxfenc.c: -1,0,2,4,6,8,10 ..... to be right, first dts should be -2.
> >>>
> >>> Maybe Im wrong or compute_frame_duration should only take codec timebase
> >>> into account and then compute_pkt_fields2 will rescale according to
> >>> stream timebase.
> >>>
> >>> What would be correct behaviour ?
> >>>
> >> Ping ? Has somebody an idea about that ? Michael ?
> > 
> > of course should the first dts be ideally -2 (or 0,2,4,... and the pts be
> > increased accordingly) i know it doesnt work currently, its a bug ...
> 
> One solution is to take only avctx timebase into account for frame
> duration then rescale to stream one if needed. That way I have -2.
> IMHO frame duration does not actually depend on stream timebase.

no, this function is used for demuxing too, and there are for example
odivx in avi with codec timebase 1/1 and container 1/15 (later being
correct) or h263 in some container with the codec timebase 1001/30000
(the only value supported by h.263) and the container having the correct
timebase

so yes the codec/stream decission could probably be improved but its not
so simple (for demuxing r_frame_rate might be worth a try if that is 
initalized already at that point?, for muxing always using the codec
timebase might work but both need extensive testing)
another solution is to take the minimum or average difference between
a few frames somehow ...

yet another is to require the user app to set the dts of the first
frame (this one seems like a good idea anyway ...)


> 
> > then theres the question what to do about frames with pts
> > 0,2,5,6,9 (or any other random series)
> > its trivial to calculate the dts for frames 1, 2, ... but what about 0?
> > what is the correct dts for it?
> 
> Well, one solution is to set dts of the frame 0 to -codec_delay,
> H264 with B pyramid is -2, normal b frames is -1.
> That should work, no ?

the stream above is variable fps, codec_delay would be 1

but yes codec_delay*average_frame_duration (if we would know the later)
would be a reasonable guess

[...]

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