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

[Michael Niedermayer]

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
-------------- 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/nut-devel/attachments/20080205/b260fdaf/attachment.pgp>