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