[MPlayer-dev-eng] [spyder at matroska.org: Re: rethinking nut!] NOVIRUS

[Michael Niedermayer]

Hi

On Thursday 01 April 2004 21:24, Moritz Bunkus wrote:
> Encapsulated message
>
>
> Re: rethinking nut!
>
> From:
> John Cannon <spyder at matroska.org>
>
>
> To:
> mosu at matroska.org
>
>
> Date:
> Today 21:08:29
>
> D Richard Felker III wrote:
> > I got to thinking some more about NUT (formerly known as MPCF, i.e.
> > MPlayer Container Format), and well, I think we might want to make
> > some major design changes.
> >
> > Why? Well, Alex was implementing NUT support in ffmpeg/libavformat,
> > and one of the main reasons he slacked off was that it was too painful
> > to do the audio subpacket buffering stuff right with libavformat's
> > design. Yes, maybe this means lavf sucks...but IMO it also means NUT
> > is overcomplicated.
>
> I wouldn't say it's really overly complicated though i haven't done any
> subpacket handling in my code yet.  One thing I found very aggravating
> though is the inconsistency in packet structure.  All packets except the
> frame packets have the packet header immediately following the startcode
> (if there is a startcode).  The frame packets however have that one byt
> between them which IMO should be moved to the packet body.  Is there a
> real reason why this belongs before the header?  It just makes my C
type 0 frames: frame_code
type 1 frames: frame_code, packet_header
type 2 frames: startcode, frame_code, packet_header
so if we change type 2 to be startcode, packet_header, frame_code it would be 
inconsistant too as type 1 must have them in the opposite order to be 
decodeable

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