[MPlayer-dev-eng] Flaming NUT

[D Richard Felker III]

On Fri, May 07, 2004 at 03:04:41AM +0200, Tristan Seligmann wrote:
> On Fri, May 07, 2004 at 03:48:02 +0300, Ivan Kalvachev wrote:
> > Do you know the SEP syndrome? It is very popular in (post) socialist
> > countries with heavy bureaucracy. It mean "Somebody Else Problem".
> > You simple try to move the problem, not to solve it. The fun comes when
> > the one that you have moved the problem to, comes with SEP in turn...
> 
> On the other hand, you don't want to make everything your problem. I
> mean, since people might not properly implement their NUT demuxer, maybe
> you should turn NUT files into DLLs that include the demuxing code
> necessary to play them...

ROTFL! Actually I was just thinking earlier today about a theoretical
container with a minimal bytecode interpreter, and instructions in the
global header for parsing startcodes/datasize/timestamp out of the
actual codec packets themselves (if present) so you wouldn't have to
encode these values in separate muxer headers... ;)

But yes, of course it's lame.

> It's an extreme example, but my point is that trying to include
> everything in one component often just leads to MS-ware bloatedness.

Agree totally.

> > > Seeking in NUT with no index is O(log n). You always seek to the exact
> > > time you want.
> > 
> > I'm already sick of this O(log n). IT IS FALSE. IT IS NOT CORRECT.
> > It is larger.
> > Why? Because you need to find frame_header first. You jump in a middle
> > of the frame data. Then you need to start reading forward until you find
> > startcode. This takes time. So it depends on data_size and type0 max size.
> 
> Unless you somehow figure that reading forward to find a startcode is of
> greater magnitude than log n, then it IS O(log n).

Actually you're considering the wrong operation. The log n comes from
the number of seeks required for the binary-search operation. The
startcode search is O(1) with constant proportional to max_distance
(between startcodes).

> > > > 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...
> > >
> > > This belongs in the PROTOCOL, not the file format. They are two
> > > entirely separate layers.
> > 
> > SEP
> 
> What's the point of building priority or retransmission into a format
> that isn't intended exclusively for stearming? What do those concepts
> mean when you're reading a NUT container from disk? This is SEP, but
> it's a perfectly valid case of SEP IMHO.

Agree totally.

> > > On the other hand, if you're copying a DVD to share on P2P ;), or
> > > streaming video (where the PROTOCOL ALREADY HAS ERROR DETECTION AND
> > > RETRANSMISSION), then you and use very few startcodes, since you have
> > > other ways of repairing the data if it's damaged.
> > 
> > Looks like you haver had dealed with floppy disk, or cd-roms, or dvd
> > burners. What would you do if this is the only copy that exist?
> > Relaying on pirate networks is not something I would do.
> 
> So you want to build error correction into every single file format that
> you might want to store on floppy disk or cd-rom or DVD? That sort of
> functionality belongs on a lower layer, that isn't dependent on the
> specific file data.

Agree totally. It's nice to be able to generally use a file that has
some damage in it, in case of emergency. But incorporating advanced
recovery features that waste space into the basic file format is
silly, since they belong at a different layer where they can be
tailored for the particular usage (streaming, scratchable media, rf
broadcast, ...).

Rich