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

[Michael Niedermayer]

On Sun, Feb 03, 2008 at 10:30:22PM -0500, Rich Felker wrote:
> On Sun, Feb 03, 2008 at 09:47:24PM +0000, Måns Rullgård wrote:
> > Michael Niedermayer <michaelni at gmx.at> writes:
> > 
> > > Hi
> > >
> > > On Sun, Feb 03, 2008 at 03:27:54PM -0500, Rich Felker wrote:
> > > [...]
> > >> Also it might be worth mentioning that multiple 'tracks' could be
> > >> stored as chapters using info packets to label them, but if so they
> > >> obviously need to be timed one after another rather than all starting
> > >> at time=0.
> > >
> > > Different content (compared to different viewpoints/encodings) of something
> > > should not overlap timewise to begin with. If thats unclear it should be
> > > clarified! (I assume you are thinking of recording several radio stations
> > > or something like that, IMHO that should be done to seperate files or the
> > > result should be remuxed at the end)
> > 
> > I guess this means NUT is not intended to be used in typical broadcast
> > environments where each channel has far more bandwidth than a single
> > program requires.  This is why MPEG-TS supports multiple independent
> > programs.
> 
> There's nothing keeping you from partitioning a physical channel via a
> separate protocol layer. For example, a DSL line has far more
> bandwidth than needed to watch youtube, but that doesn't mean that
> html, email, etc. is interleaved into the FLV container!! Rather, you
> have TCP for multiplex unrelated connections over a single physical
> network line. The same principle applies to broadcast channels as
> well. There is no excuse for container/transport incest!!!!!

Thats all nice and well, just that the reason why nut cant be used directly
is because of maybe 2-3 lines in the spec. And as solution you suggest
an additional protocol layer. Which is equivalent to double layer muxing.
Which actually violates the spec ...
And which i then have to somehow support in ffmpeg in addition to mpeg-ts
and everything else that implements things the other way around.

Well i wont implement it. Feel free to send a patch, but expect me to
reject it if its 1000+ lines.

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

Thouse who are best at talking, realize last or never when they are wrong.
-------------- 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/20080204/bf1a5da2/attachment.pgp>