[MPlayer-dev-eng] a few nut suggestions [timestamps]

[D Richard Felker III]

On Wed, Oct 06, 2004 at 01:58:25PM +0200, Michael Niedermayer wrote:
> > - with a real stream we have a lot more things we can check to see if
> >   the candidate chain makes sense, like interleaving. a false chain
> >   will have the streams appearing in rather random order, so it's at
> >   least somewhat unlikely for the pts interleaving to match.
> 
> yes, but if we resync after an error, which is the purpose of all this we dont 
> have a valid last timestamp or the past pts values to calculate the dts 
> values which are monotone, so the interleaving check while possible will need 
> a full or lsb timestamp in at least 2 streams before it could detect an 
> inconsistency, now such timestamps arent common as they are a waste to space 
> normally

this stuff got me thinking that maybe in some cases the relative pts
is undesirable. i don't want to propose removing it since it's very
useful for single-stream stuff at low bitrates where you don't really
care if the pts gets messed up a little bit when there's data loss.
but maybe we should also allow framecodes to code lsb_timestamp.

why? it seems like using some bits of framecode for lsb timestamp
would be a big waste, and maybe that's the case. but they also (via
interleaving rules) provide a strong criterion to throw out bad
chains, probably well enough that getting a bad chain is very very
unlikely. but i'm not quite sure how it would work, whether we'd need
lsb_lsb_timestamp and msb_lsb_timestamp, etc.. just an idea.

rich