[Mplayer-cvslog] CVS: main/DOCS/tech mpcf.txt,1.54,1.55

[D Richard Felker III]

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... :)

Rich