[MPlayer-dev-eng] The NUT backward pointers

[Michael Niedermayer]

Hi

On Monday 12 April 2004 18:46, D Richard Felker III wrote:
> On Mon, Apr 12, 2004 at 06:10:38PM +0300, Ville Saari wrote:
> > What if the nut packet header were split in two so that the backward
> > pointer is stored at the end of the previous packet instead?
> >
> > If bitstream is examined at the middle of the file, only the order of
> > the forward and backward pointers would change. However the unnecessary
> > backward pointer at the beginning of the file would be eliminated and
> > and extra backward pointer would be added at the end of file which would
> > make the end of file a possible point to catch the sync from.
> >
> > A packet in the current specification is like:
> >
> >   size of packet n
> >   size of packet n-1
> >   data of packet n
> >
> > And the change I'm proposing would turn it into:
> >
> >   size of packet n
> >   data of packet n
> >   size of packet n
u seem to forget that there may be 8 byte startcodes at the begin of 
packets ...

>
> Michael would have to comment. I'm not sure what all the implications
> of this change would be, especially with type-0 frames.
the first problem is that the current vlc code used cannot be decoded in 
backward direction
when we look just on the msb bit of each byte, which are the only ones upon 
which the length depends:
0
10
110
1110
it is immediately obvious that this is identical from the right, it would be 
possible to change the vlc code into a reversible one:
0
11
101
1001
but that would be somewhat more complicated to write & parse, but iam not 
against this change, actually i think that the rvlc may be good idea

another problem is that the length of the 2 pointers is included in their 
value, so when u have a 126 byte packet, 126 can be stored in 1 byte, but 
with the 2 pointers its 128 byte long so it will need two 2 byte pointers, 
and be 130 bytes, not that this is much worse then the current solution, 
currently we just need to patch the forward pointer, but with the proposed 
system we would need to be carefull as a simple put_v() couldnt be used to 
write the second one
we could also decide to not count the length of the 2 pointers in the packet 
size, but that would complicate the demuxer

and as rich already suspected it may also be problematic for type 0 frames, as 
normally we just check the framecode after a type 0 frame, its either another 
type 0 or type 1 frame or a 8byte startcode with a type 2 frame, but with the 
proposed variant there would be a type 0 startcode vs. length vlc case, this 
could be differentiated by using the last frame 1/2 size but its not a 
beatifull solution IMHO, so iam against this unless someone has a good 
argument why this would be better then the current solution

btw, we could also require the encoder to put a main header copy at EOF so 
there would always be a startcode close to EOF from which a decoder could 
follow the pointer chain

[...]
-- 
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