On Tue, Feb 05, 2008 at 12:14:12PM -0500, Rich Felker wrote: [...]
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.
The generic info packets would have allowed to store menus.
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.
You might, none of the users will, they will more likely just transcode it to matroska and use the resulting single file. And if that happens not to work with a player they will choose a different player. Its a simple thing, nut either supports what people want, and the way people want or people will use another container. Technical details have very little effect on user decissions.
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.
Well people do up and download mpeg-ts to mphq :)
except perhaps as a link between devices involved in the actual broadcast.
Yes, you mux your mpeg-ts maybe in realtime, maybe off line and then transmit it. Nut current cannot be used as replacement. It requires a second layer which outweights its advantages over mpeg-ts. Not a single person said they would even consider nut as an replacement, dont you think thats maybe an indication that you are moving in the wrong direction? And when you speak about partitioning, dont forget that all timing and buffering constraints must be met. All the packets must be transmitted so the decoder buffers neither over nor underflow. Theres no feedback saying stop or saying "i want more packets". Spliting this over 2 layers is not going to make it much simpler. And that reminds me, for broadcast, we might need an additional timestamp to synchronize the decoder. Oterwise clock drift between decoder and encoder can cause buffer over/underflows. This also affects single program per nut. But i assume the mystery protocol takes care of that as well. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway