Re: revisions for nut-english.txt?

Hi

On Tue, Feb 05, 2008 at 01:21:33AM -0500, Rich Felker
wrote:
[...]
> > And the protocol "whatever its called
;)" will give you a multi nut in your
> > case, like it or not. You will either need a
double layer protocol or double
> > layer demuxer. Because mpeg-ts comes out of it
currently, and if you replace
> > it by your protocol+nut, then your protocol+nut
will come out.
> 
> Depends on what you're talking about it "coming
out" of. No one says
> that an interleaved mess of video, html, email, pings,
etc. comes out
> of the ethernet, because there's an appropriate layer
delivering to
> the application only the data it's interested in (and
which belongs to
> it).
> 
> 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.
With your design, he has to transcode this into maybe 50+
files somehow kept
together in an archive, lets say a .tar. With some
unspecified way to store
menus and all the support structures.

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

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
not a natural part of file io to turn your single file into
50 streams easy
useable and seekable by the demuxer. And i dont even want to
start thinking
about non seekable input or what effect that would have on
complexity.

[...]
-- 
Michael     GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act
responsibly, while bad
people will find a way around the laws. -- Plato

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel