[MPlayer-dev-eng] The NUT backward pointers
Michael Niedermayer
michaelni at gmx.at
Mon Apr 12 21:53:12 CEST 2004
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
More information about the MPlayer-dev-eng
mailing list