[MPlayer-dev-eng] Cleaning your nuts

[D Richard Felker III]

On Thu, Apr 22, 2004 at 05:32:06PM +0200, Michael Niedermayer wrote:
> > Ivan has pointed out that the bidirectional pointers are better in
> > some cases, since you can walk backwards from the next startcode to
> > get data after the point of corruption. But this doesn't seem to work
> > well with header prediction/compression. Also, checking that
> > forward/backward pointers match isn't necessarily so easy, since a
> > common form of corruption is a uniform byte value over the damaged
> > region. And this sort of recovery requires seeking quite a few times,
> > rather than just continuing to read forward.
> there are a few more issues with the bidirectional pointers / type 1 frames, 
> the pointers needed 4bytes per packet while the startcode needs 8byte, a 
> simple improvement would be to add the type 1 packets again but with a 4byte 
> startcode instead of pointers, that way the overhead would be smaller then it 
> ever was (no pointers in type 2 frames) and it would be simpler then the 
> bidir pointer case, furthermore as a type 1 packet search would only be used 
> in the case of actual damaged frames the 1 missdeection in 4gb shouldnt be an 
> issue
> probably 3byte startcodes would be enough for these?

Good ideas to think about...

> lsb timestamps should be enough for these packets too, so i guess the type 1 
> headers would be 50-70% smaller then type 2

BTW we should address the msb/lsb/relative timestamp issue. My
proposal has been to get rid of msb/lsb thing and just use relative
timestamps for type0 (and type1?) frames if possible. But maybe the
lsb thing is more robust in the presence of errors. IMO relative is
much more compact, especially with the 3 delta predictors.

> there are several other ideas i have how error recovery with low overhead 
> might be possible, but they all have a serious disadvantage:
> 1. possibility: use the startcodes in the video or audio stream, mpeg4, 
> mp3, ... have startcodes which could be used for recovery and even for 
> finding the size of a frame, it introduces an ugly codec-muxer dependancy and 
> wont work with all codecs ...

Maybe this could optionally be used for codecs that support it, but I
agree it's rather kludgy.

> 2. possibility: use 2byte startcodes, and escape all occurances of this 2byte 
> code in the stream, we wouldnt even need to store the packet size in this 
> case, but theres the (un)escaping which needs to be done which wastes cpu 
> time, we could also use a few bits (~4) of these 2 bytes as flags

IMO this is totally unacceptable. The cpu overhead for high bitrate
mpeg2/4 would be insane.

> > Caveats: Before writing any packet, the muxer must know that no other
> > stream will want to write a packet before it. Either the muxer can
> > buffer one packet in each stream, or the calling app can just call the
> > muxer in the proper order.
> further caveat, do we use the timestamp of the first, last or middle sample of 
> an audio frame?

I was just thinking about it this morning. IMO all timestamps must be
for the very beginning of the frame. (This applies to video too since
sometimes a video frame is 2 fields.) Beginning is the only useful
piece of information to know for the player. If the timestamp is the
middle or end, you have to know the decoded length of the frame in
order to get the beginning timestamp, which is the important piece of
information. Also, anything but beginning timestamp would be
disastrous for proper interleaving, especially with subtitle packets!

> > 2. Get rid of framecode and replace it with something non-obfuscated.
> > [...]
> > Rationale: Meets the simplicity goal and perhaps improves error
> > recovery.
> simlicity, yes,
> error recovery IMHO no, its easily possible to require 50% of the framecodes 
> to be invalid to detect errors

Then you only have a 50% chance of catching an error, and you added
lots of overhead. Bad tradeoff.

> maybe i should mention here that for CBR audio there will only be 2 sizes, 
> like 125 and 126, never another, and for vorbis there are 128 and 1024 sample 
> packets, their bitstream size also differs similarely

I'm aware. But CBR rather sucks... If we really wanted we could have a
global header that indicates CBR and the 2 sizes, and then store the
data size as one bit in the header_field (see my proposal).

But, IMO this isn't really worthwhile. Someone using CBR obviously
doesn't care about file size...

Rich