[MPlayer-dev-eng] Nut startcodes

[Michael Niedermayer]

Hi

On Monday 26 April 2004 12:20, D Richard Felker III wrote:
> Michael proposed (in "Cleaning your nuts" thread :) adding "type 1"
> frames back into nut with 3-byte startcodes to improve error recovery.
> What's everyone's opinion on this?
>
> BTW, the spec right now is rather confusing regarding type 2 frames. I
> have a proposed simplification. Get rid of frame "types" entirely and
> just have frames and startcodes be two separate things. An 8-byte
> startcode just serves as a sync point, and frames after the startcode
> are forbidden from using any predictive coding that depends on frames
> before the startcode. As a consequence, the first frame of each stream
> after the startcode must fully encode its pts. In effect it's the same
> thing as type 2 frames, but conceptually, it's nicer to separate the
> startcode from the frame so that it doesn't belong to any particular
> stream, but rather the file.
agree

>
> In this light, there's only one type of frame, and two types of
> startcodes (not counting global/stream header, info, etc. startcodes):
>
> 1. Small (3-byte?) startcode. This one imposes no rules on the
>    surrounding frames, and serves ONLY as an aid to error recovery. It
>    can be used as frequently or infrequently as desired for the
>    error-recovery needs of the user.
agree, but there are 2 things which may need disscussion

1. length? this depends upon what demuxer complexity we assume, for example, 
if we assume that the demuxer follows all possible pointer chains as u 
suggested then 2 or even 1 bytes could be interresting, but if a demuxer just 
seraches for the next startcode and blindly starts decoding from there 3 is 
probably the minimum

2. what value should the startcode get? first byte has to be 'N', should the 
following be stored in the main header? an advantage may be that a smart 
muxer could choose a code which occures less often in the streams, i suspect 
that some bit sequences may be quite rare, especally in formats which try to 
avoid some sequences

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en