[MPlayer-dev-eng] Flaming NUT

[Tristan Seligmann]

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

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

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

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

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

-- 
mithrandi, i Ainil en-Balandor, a faer Ambar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20040507/aa79d3c2/attachment.pgp>