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