[MPlayer-dev-eng] Flaming NUT

[Ivan Kalvachev]

Hello,
Maybe you have noticed that I am not including myself in nut discussions anymore.
Why?
I looked at older (20030906) version on nut and I found that I like it
more, as it is nearly what I have proposed. From this fact I think that
nut is heading in a wrong direction. Michael is great optimizer,
but I will repeat again (and again) that reducing overhead is not our
primary goal!
I found something interesting too. The old draft have more
requirements for error resistance! Cheaters.)

So, I will try to explain one more time my point of view.

1. The format is not extendible.
"allow adding more fields at the end of headers".
This also include frame headers!
After all, the main function of container is to keep the frame data
and all other meta data that is required for it.

Just turn back and see what beautiful hack you have done for DTS support.

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


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.


3. Seeking ATM is something horrible. The place of index is not
determined by any way. It may come to the confusing situation to read
the half (or whole) file until index is found:O
Seeking without index is very similar to the mpeg stream seeking.
With the tiny detail that nothing guarantee that these startcodes are
unique, just very improbable.
Do you remember the nut it nut scenario. 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.


4. I am serious about NUT in MPEG-TS. Really.
You are trying to reduce the overhead of NUT, with words that it is
good for very low bitrate streams. But these streams are good only for
streaming. And NUT is not suited for streaming. No packet priority
no retransmition etc...


5. The current level of error resistance ability is somehow lower
than MPEG-(P)ES. Why? If there is broken frame_header of type0 frame
then we will loose all frames until next type2. This may mean up to
0.5 seconds (15 frames) or even more (>16kb) data.
Just for compartment with mpeg elementary stream you may resync on next
slice in the same picture!
If some player need error recovery it is better to completely ignore NUT
demuxer and search mpeg startcodes in the data.


6. There is no way to find error in the frame headers or frame data,
unless something really bad happens (hit impossible value). Even then
the damaged region could not be exactly determined :(

Do you remember the scenario I was trying to convince you while I was
studding NUT? It was not possible because of backwards pointers. But now
it is:
If there is one broken byte in frame_code of type0, it is very probable
that demuxer won't detect it and will return data_frames. It may
calculate wrong size of frame and will read wrong frame_code for next
frame. Same will repeat until summary size grows beyond the limit. But
as the size is variable now, it could become quite big mess.


7. The size test are done in best conditions. We don't have real test
stream that could be used for comparing results. Every test is unique
and unrepeatable. Of course nut will beat every container in CBR mp3, except
mp3, as it have monotone timestamp
s, (nearly) constant
framesize and only one stream. So what?
We need an real stress test, for worst scenario.


-


Non of these problems are fatal. Most of the time nut will work.
Making container better than avi is not big deal.
Don't forget that OGG is quite good container and only one
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;)

You know that a chain is as strong as it weakest branch.

Best Regards
   Ivan Kalvachev
  iive

p.s.
Yes, it is possible to create container with even lower overhead, that
is more simple and error resistant. But it looks like all current nut's
are against any kind of buffering.(
But I want to delay that project after I hove some working vo3.

p.s.2
sorry I missed matroska flaming...