Re: Recommendations for DEMUXER layer

On Mon, Dec 29, 2003 at 08:53:40PM +0100, Arpi wrote:
> Hi,
> 
> > > > OK, one more...
> > > > 
> > > > 3. PTS handling is really bogus in some demuxers. Sometimes ds->pts is
> > > >    scaled by rate_d, sometimes not.
> > > 
> > > WTF?
> > 
> > AVI demuxer outputs rate_m*framenumber for pts.
> 
> huh?
> ah, i think i remember now. it was more clever idea behind it.
> to get frame number:  frameno=ptsvalue/rate_d
> to get time position: seconds=ptsvalue/rate_m
> and ptsvalue is always integer and can produce accurate values for
> both things.
> 
> so, demuxers for formats storing frame/chunk number (avi) will scale by
> rate_d, demuxers for timestamp-based formats (asf) will scale by rate_m
> so for both kind of formats, only integer*integer multiply is done,
> so no bit loss :)

Timestamps are not necessarily in units of 1/rate_d!! They can (and
SHOULD, to avoid wasting space) be in units of rate_m/rate_d, e.g.
1001/24000. With your method, pts would increase by 1001 per frame for
avi or ntsc nut, and the output encoder/muxer would have no way of
knowing that it should use 1001/24000 time units rather than 1/24000.

Either method (yours or mine) allows you to get exact values for
frame[/tick] number or timestamp. In my method, frame/tick/sample
number is "pts" and timestamp is "pts*rate_m/rate_d". In yours,
frame/tick/sample number is "pts/rate_m" and timestamp is
"pts/rate_d". Either works (yours is just scaled by rate_m, but still
always divisible by rate_m), but the reason I prefer my method is that
you keep time units as large as possible in the output, allowing the
encoder/muxer (for mencoder g2) to be as efficient as possible without
the user having to manually override time units.

> > > > My recommendation is for pts to always be in units of rate_d/rate_m.
> > > 
> > > it _IS_
> 
> ok, it isn't... i was wrong :)

:)

Rich