[NUT-devel] CVS: main/DOCS/tech mpcf.txt,1.145,1.146

[Rich Felker]

On Mon, Mar 13, 2006 at 03:21:08AM +0100, Michael Niedermayer wrote:
> > Hmm, one thing that needs consideration though is if there's a limit
> > on the number of timebases. Up until now we never worried about limits
> > on the number of streams since we assumed a demuxer could just ignore
> > streams it's not interested in. However due to universal timestamp,
> > the demuxer needs to be aware of all timebases in the file. Should we
> > address this, or just assume that a super-limited demuxer can reread
> > the list from the main header if it needs to?
> > 
> > Sorry for bringing up a nasty issue -- I just realized it.
> 
> the problem was already there before the "universal timestamps" as they are
> just a cosmetical change, syncpoints already contained stream+timestamp in
> stream timebase ...

Yes, this is what I meant. Sorry for not being clear.

> id at least add a note like
> muxers should have mercy with weak demuxers and not create more timebases
> then needed
> muxers should not round timestamps, but store exact ones
> there MUST not be 2 identical timebases in a file

These are all reasonable.

> it doesnt solve the problem but should reduce it at least, we could
> certainly solve it but iam not sure if its a good idea, i rather tend
> toward that a complete fix would have too many dissadvantages

I tend to agree. I don't want to limit the number of streams in a
file, and limiting the number of timebases would implicitly do that.

> for example one way to fix it is to:
> universal_timebase_count MUST be < CONSTANT
> 
> universal_timestamp
>     tmp                     v
>     stream_id= tmp % (universal_timebase_count+1)
>     tmp /= (universal_timebase_count+1)
>     if(stream_id < universal_timebase_count)
>         timestamp= tmp * timebase[ stream_id ]
>     else{
>         den                 v
>         timestamp= tmp/den
>     }
> 
> or something similar

Yes, this would work but it's ugly...

Rich