[MPlayer-dev-eng] Flaming NUT

[Michael Niedermayer]

Hi

On Tuesday 04 May 2004 01:07, D Richard Felker III wrote:
> On Tue, May 04, 2004 at 01:25:19AM +0300, Ivan Kalvachev wrote:
[...]
> > Oh I am sure that you will may extend frame_code to add additional bits
> > that will indicate additional fields. Maybe frame_codes won't be
> > enough?
> > I guess that escape_frame_code (e.g. 0xFF) could be used, so you will
> > still have about 250 normal codes. Of course escaped code will grow to
> > minimum 2 bytes  :( Not to mention main and stream header changes...
>
> Maybe you have some points about the current structure not being
> extensible enough. I'll check and recommend any necessary changes. IMO
> there should be a number before the framecode table, which tells how
> many vlc-coded fields will follow for each framecode. That way we can
> add new fields that can be ignored by old players.
agree

>
> > 2. I wanted more checksums (in frame headers too). Rich explained me
> > that they are not necessary as backward/forward pointers are the
> > biggest part of the header and breaking one of them is easy to be
> > found. Few days later Michael removed the backward pointers.
> > Of course nobody want to spend  precious bytes for checksums.
>
> Checksums ARE NOT NECESSARY to identify damage. Startcode checking
> does a much better job of the same thing, with less computational
> overhead (I sure as hell don't want to be wasting cpu cycles on
> checksums when I'm trying to get my k6 to decode 720x480 video with
> he-aac audio.....).
ivan, maybe u want to mux your nut files with only 2 valid frame-codes and vlc 
code everything afterwards, that way theres is a _lot_ of checking done (99% 
of the frame_code bytes are invalid, 99% of the stream_id vlc too, ...)

[...]
>
> > Do you remember the nut it nut scenario.
>
> Nut is not allowed to contain other containers (including itself),
> only raw codec frames.
>
> > It could make nut demuxer
> > completely nuts on seeking, dumping errors that don't really exist.
> > Ya,ya even ogg don't do it anymore.
>
> You can come up with pathologies that break any system of sync/error
> recovery.
>
> > 4. I am serious about NUT in MPEG-TS. Really.
just be carefull not to put mpeg-ts in mpeg-ts :)

[...]
> > Don't forget that OGG is quite good container and only one
>
> ROTFL!!!

> > small (design) error banned it from broad usage. Now there is OGG2 in
> > development and if there is even single problem in NUT it may be doomed.
> > (Not to mention matroska;)
>
> FUD.
yes, iam scared, the idea of having to deal with ogg2 scares me, ffmpeg still 
has some problems with ogg1, which wont disapear until someone adds code to 
extract the timestamps from vorbis packets, but thats not easy, i already 
looked at libvorbis ...

[...]

-- 
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