CVS change done by Oded Shimon CVS Update of /cvsroot/mplayer/main/DOCS/tech In directory mail:/var2/tmp/cvs-serv227/DOCS/tech Modified Files: mpcf.txt Log Message: bump neglected date more consistent notation (usually in specs there are only arrays, no structs...) Index: mpcf.txt =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/tech/mpcf.txt,v retrieving revision 1.145 retrieving revision 1.146 diff -u -r1.145 -r1.146 --- mpcf.txt 12 Mar 2006 17:35:51 -0000 1.145 +++ mpcf.txt 12 Mar 2006 17:40:32 -0000 1.146 @@ -1,5 +1,5 @@ ======================================== -NUT Open Container Format DRAFT 20060207 +NUT Open Container Format DRAFT 20060312 ======================================== @@ -106,7 +106,7 @@ t (v coded universal timestamp) tmp v stream_id= tmp % stream_count - value= (tmp / stream_count) * stream[ stream_id ].timebase + value= (tmp / stream_count) * timebase[stream_id] Bitstream syntax:
On Sun, Mar 12, 2006 at 06:40:35PM +0100, Oded Shimon CVS wrote:
CVS change done by Oded Shimon CVS
Update of /cvsroot/mplayer/main/DOCS/tech In directory mail:/var2/tmp/cvs-serv227/DOCS/tech
Modified Files: mpcf.txt Log Message: bump neglected date more consistent notation (usually in specs there are only arrays, no structs...)
Index: mpcf.txt =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/tech/mpcf.txt,v retrieving revision 1.145 retrieving revision 1.146 diff -u -r1.145 -r1.146 --- mpcf.txt 12 Mar 2006 17:35:51 -0000 1.145 +++ mpcf.txt 12 Mar 2006 17:40:32 -0000 1.146 @@ -1,5 +1,5 @@ ======================================== -NUT Open Container Format DRAFT 20060207 +NUT Open Container Format DRAFT 20060312 ========================================
@@ -106,7 +106,7 @@ t (v coded universal timestamp) tmp v stream_id= tmp % stream_count - value= (tmp / stream_count) * stream[ stream_id ].timebase + value= (tmp / stream_count) * timebase[stream_id]
BTW an idea... instead of having timebase stored in the stream header, what if we stored a list of timebases in the main header, then the stream header just had an index into that list? That was if we had 20 different streams but only 2 distinct timebases, the universal timestamps would still be compact. It would also allow additional non-stream timebases to be stored for use in chapter extents. Rich
Hi On Sun, Mar 12, 2006 at 01:05:48PM -0500, Rich Felker wrote:
On Sun, Mar 12, 2006 at 06:40:35PM +0100, Oded Shimon CVS wrote:
CVS change done by Oded Shimon CVS
Update of /cvsroot/mplayer/main/DOCS/tech In directory mail:/var2/tmp/cvs-serv227/DOCS/tech
Modified Files: mpcf.txt Log Message: bump neglected date more consistent notation (usually in specs there are only arrays, no structs...)
Index: mpcf.txt =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/tech/mpcf.txt,v retrieving revision 1.145 retrieving revision 1.146 diff -u -r1.145 -r1.146 --- mpcf.txt 12 Mar 2006 17:35:51 -0000 1.145 +++ mpcf.txt 12 Mar 2006 17:40:32 -0000 1.146 @@ -1,5 +1,5 @@ ======================================== -NUT Open Container Format DRAFT 20060207 +NUT Open Container Format DRAFT 20060312 ========================================
@@ -106,7 +106,7 @@ t (v coded universal timestamp) tmp v stream_id= tmp % stream_count - value= (tmp / stream_count) * stream[ stream_id ].timebase + value= (tmp / stream_count) * timebase[stream_id]
BTW an idea... instead of having timebase stored in the stream header, what if we stored a list of timebases in the main header, then the stream header just had an index into that list? That was if we had 20 different streams but only 2 distinct timebases, the universal timestamps would still be compact. It would also allow additional non-stream timebases to be stored for use in chapter extents.
ok [...] -- Michael
On Sun, Mar 12, 2006 at 10:53:03PM +0100, Michael Niedermayer wrote:
@@ -106,7 +106,7 @@ t (v coded universal timestamp) tmp v stream_id= tmp % stream_count - value= (tmp / stream_count) * stream[ stream_id ].timebase + value= (tmp / stream_count) * timebase[stream_id]
BTW an idea... instead of having timebase stored in the stream header, what if we stored a list of timebases in the main header, then the stream header just had an index into that list? That was if we had 20 different streams but only 2 distinct timebases, the universal timestamps would still be compact. It would also allow additional non-stream timebases to be stored for use in chapter extents.
ok
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. Rich
Hi On Sun, Mar 12, 2006 at 05:15:04PM -0500, Rich Felker wrote:
On Sun, Mar 12, 2006 at 10:53:03PM +0100, Michael Niedermayer wrote:
@@ -106,7 +106,7 @@ t (v coded universal timestamp) tmp v stream_id= tmp % stream_count - value= (tmp / stream_count) * stream[ stream_id ].timebase + value= (tmp / stream_count) * timebase[stream_id]
BTW an idea... instead of having timebase stored in the stream header, what if we stored a list of timebases in the main header, then the stream header just had an index into that list? That was if we had 20 different streams but only 2 distinct timebases, the universal timestamps would still be compact. It would also allow additional non-stream timebases to be stored for use in chapter extents.
ok
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 ... 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 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 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 [...] -- Michael
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
On Sun, Mar 12, 2006 at 01:05:48PM -0500, Rich Felker wrote:
On Sun, Mar 12, 2006 at 06:40:35PM +0100, Oded Shimon CVS wrote:
- value= (tmp / stream_count) * stream[ stream_id ].timebase + value= (tmp / stream_count) * timebase[stream_id]
BTW an idea... instead of having timebase stored in the stream header, what if we stored a list of timebases in the main header, then the stream header just had an index into that list? That was if we had 20 different streams but only 2 distinct timebases, the universal timestamps would still be compact. It would also allow additional non-stream timebases to be stored for use in chapter extents.
? - ods15
On Mon, Mar 13, 2006 at 09:31:16AM +0200, Oded Shimon wrote:
On Sun, Mar 12, 2006 at 01:05:48PM -0500, Rich Felker wrote:
On Sun, Mar 12, 2006 at 06:40:35PM +0100, Oded Shimon CVS wrote:
- value= (tmp / stream_count) * stream[ stream_id ].timebase + value= (tmp / stream_count) * timebase[stream_id]
BTW an idea... instead of having timebase stored in the stream header, what if we stored a list of timebases in the main header, then the stream header just had an index into that list? That was if we had 20 different streams but only 2 distinct timebases, the universal timestamps would still be compact. It would also allow additional non-stream timebases to be stored for use in chapter extents.
?
Committed - ods15
participants (4)
-
Michael Niedermayer -
Oded Shimon -
Rich Felker -
syncmail＠mplayerhq.hu