[Mplayer-cvslog] CVS: main/DOCS/tech mpcf.txt,1.54,1.55
D Richard Felker III
dalias at aerifal.cx
Sun May 2 19:25:53 CEST 2004
On Sun, May 02, 2004 at 02:01:00PM +0200, Michael Niedermayer wrote:
> > How do short startcodes add 3+1*stream_count overhead? This is
> > nonsense. They add constant overhead of 3 bytes per startcode, nothing
> > more.
> but then the timestamps will be random
> for example, we loose 1 frame, and realize it immedeatly, in reality there
> will be a few random headers decoded without realizing it ...
> actual pts: 0I 3P 1B 2B 6P 4B 5B 9P 7B 8B
> LRU2: 3 2 1 3 -2 1 4 -2 1 4
> LRU1: 2 1 3 -2 1 4 -2 1 4 -2
> LRU0: 1 3 -2 1 4 -2 1 4 -2 1
> encoded: F 2 L 2 L 2 2 2 2 2 (F=full, L=lsb, 012=delta predicted)
> damage: X
> LRU2: 3 2 X 1 3 2 4 3 2 4
> LRU1: 2 1 X 3 2 4 3 2 4 3
> LRU0: 1 3 X 2 4 3 2 4 3 2
> decoded: F 2 X 2 L 2 2 2 2 2
> timestamp: 0 3 X 5 9 12 14 18 21 23
> so, for short startcodes we have to
> 1. reset the timestamp delta predictors
> 2. code all of the first following timestamps of each stream as lsb timestamp
> 3+1*stream_count is minimum, indeed the reseting may cause more lsb timestamps
> to follow, and lsb may be larger then 1 byte
Hm. Originally I thought we could just deal with some incorrect
timestamps following an error, but with B frames and negative deltas
(B frames are evil!!!) this is not so easy.
But coding LSB timestamps is also a big problem!! An optimal framecode
table will likely only have a few indices that allow you to code a
timestamp, and those will require coding _everything_ as vlc, i.e.
stream id, size, and timestamp. This makes the overhead for type1
startcodes almost as big as for type2!
Anyway another consequence of what you pointed out is that my "try
each byte" method of recovering after errors cannot give valid
timestamps in the presence of predictive timestamp coding.
I have a couple ideas to help remedy the situation:
1. Add additional pts coding option to the framecode table: global
deltas stored in the framecode table. Of course these would need to
be known in advance, but they're not mandatory. They're just
available for people who want optimal encoding.
2. Not sure if this decent or not... Store a list of pts deltas after
each (type2) startcode, which the muxer would base on the most
frequently appearing deltas since the previous startcode. This way
the user/codec doesn't have to provide deltas in advance in the
framecode table, but you still get an advantage similar to
prediction. On the other hand, you're in big trouble if the area
around the startcode is destroyed...
3. Just forget about type1 startcodes and recovery at arbitrary
packets, and put lots of type2 startcodes... :( Maybe it's possible
to skip fully coding the timestamps for _each_ stream after the
startcode, since the msb's for all but the first stream could be
inferred by proper interleaving and converting time bases... :)
More information about the MPlayer-cvslog