[MPlayer-dev-eng] Flaming NUT

Ivan Kalvachev ivan at cacad.com
Fri May 7 02:53:43 CEST 2004


Michael Niedermayer said:
> 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:
> [...]
> > > 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, ...)

Why should i replace 1/2^32 with 2/256?
What is the overhead if this scenario is used?
Would you make some test with real movie. Will it be better than avi?


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

MPEG-TS uses one byte startcode. But as it have fixed size
packets it is quite easy to check is this packet header or
random byte. Inserting mpeg-ts into mpeg-ts would not be so
big disaster as sync codes of the internal stream would be
in increasing offset position and won't follow the pattern.

The killer stream of mpeg-ts is stream full of sync codes. But
it won't be very usable "GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG"...


> [...]
> > > 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 ...
Well that is what I say "small design error".

If you want to make your future life easier I recommend you contact
them and say how it should be improved.
I hope they won't take your recommendations for flames;)


I'm sure that NUT would be better than most containers out there.
But it won't be THE BEST.
I want it to be THE BEST.

Best Regards
   Ivan Kalvachev
  iive





More information about the MPlayer-dev-eng mailing list