[NUT-devel] revisions for nut-english.txt?

[Rich Felker]

On Tue, Feb 05, 2008 at 02:33:10PM +0100, Michael Niedermayer wrote:
> > My intent was never for such monstrosities to be written to disk as a
> > single file, but separated at the transport level. Of course even if
> > they did remain on disk, it's like talking about zip or rar files. The
> > possibility that someone might put two separate nut programs in some
> > ugly wrapping structure on disk doesn't mean nut should support
> > multiple programs internally any more than the possibility that
> > someone might create a .rar file containing a nut file and windows
> > codec binaries together means that nut should support embedding
> > windows codec dlls in the headers...
> 
> Ill give a concrete example
> A user has a DVD with menus and some alternative scenes/chapters.
> With my design he just transcodes this in a single nut file and can play it.

You speak of your design as if there is a design under discussion.
There is not. The topic at hand is interleaving multiple unrelated
programs, which does not in any way provide support for storing DVD
menus. Nor does the current design of NUT preclude menus (though it
certainly does not encourage them) given a proper spec for the
metadata to describe them.

> With your design,

There is not "my design" but the frozen design. Aside from fixing any
minor details, which you and several others have been doing a very
fine job of, NUT is finished.

> he has to transcode this into maybe 50+ files somehow kept
> together in an archive, lets say a .tar.

The number would be more like 2. And they would not be in a .tar file
except when distributed by idiotic warez-mentality folks (and then it
would probably be .rar anyway).

> With some unspecified way to store
> menus and all the support structures.

Feel free to propose a specification for menus. I believe this was on
the agenda for a long time but considered sufficiently unimportant
(and at a separate layer of specification) that it could be relegated
to after NUT was completely finished.

> ffplay, mplayer, ffmpeg, xine, vlc, ... will then get a command line argument
> called mydvd.tar

Absolutely not. One would extract the nonsensical archive with the
normal archive tools, if such a thing were used.

> There is no mysterious protocol between the file/http/ftp/... protocol and the
> demuxer unless such new second layer protocol or demuxer is implemented. Its

Again you are mixing unrelated issues. The topic at hand is
partitioning of broadcast channels. No one in their right mind would
transmit such a multi-program broadcast stream over http/ftp/etc.
except perhaps as a link between devices involved in the actual
broadcast. It would be wasting a HUGE amount of bw for no purpose, and
if someone really did want all the programs, using a different http
link for each is the appropriate way. Thinking they would be merged on
disk and playable in that form is as ridiculous as thinking folks
would expect to be able to run mplayer with a tcpdump packet capture
file as its input...

Rich