[MPlayer-dev-eng] NUT pts/startcode optimization proposal

[D Richard Felker III]

On Tue, May 04, 2004 at 09:55:22PM +0300, Ville Saari wrote:
> On Mon, May 03, 2004 at 08:18:05PM -0400, D Richard Felker III wrote:
> 
> > > yes, error recovery, if last_timestamp is wrong by a small value lsb 
> > > timestamps will result in the correct timestamp, delta wont
> > 
> > Ville, the system is Michael describes is really very smart.
> 
> Yes. I see it now when Michael described it. It's just not too obvious
> so it might be a good idea to add some "whys" to the specification that
> currently consists mostly of just "hows". It would keep the ignorant
> people who haven't followed the discussion from the beginning, like me,
> from asking dumb questions.

A good document with the rationale behind the design decisions is
definitely something that would be nice to have. But IMO it's a
separate thing from the actual spec.

> What I said about using a constant predictor for timestamps holds for
> lsb-timestamps too: Taking the upper bits from the predicted timestamp
> instead of the raw last timestamp would increase the odds for the

Of course. This is how it works.

> By the way - did you consider what the lsb-method does to the 
> 32*32*32/(32*32)-problem? Any sufficiently accurate approximate
> solution would be fine because the residual will be eliminated
> by the next lsb timestamp.

This is only true if lsb timestamps are coded for the next frame,
which may not be the case if the muxer is using delta timestamps in
the framecode. Thus, IMO NUT needs to require the implementation to do
correct timebase conversion arithmetic. No problem though -- Michael
posted an exact solution that doesn't use more than 64 bits.

Rich