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

[Rich Felker]

On Mon, Feb 04, 2008 at 12:03:23AM +0100, Michael Niedermayer 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.
> 
> You could use nut for that but a few things wont work.
> 
> Info packets arent capable to describe such mixed content very well
> because theres no way to have an info packet apply to a program. You
> would have to duplicate the info packet for each stream in a program.
> 
> Chapters (which would differ between programs) cant overlap timewise.
> 
> Seeking with back_ptrs is at the mercy of having frequent keyframes in
> all streams. I assume this would be true for your broadcast scenario, 
> still its not optimal, but also not worse than mpeg-ts.
> 
> Possible changes to nut which would improve this would be.
> * returning to the original info packets as i designed them, to store
>   generic information. (this would fix the first 2 issues)
> * multiple back_ptrs for such multi program/track files/streams

I don't consider this an improvement. Muxing unrelated content is a
HARMFUL activity (makes it more resource-intensive to process with no
gains) and outside the scope of NUT. The whole purpose of interleaved
muxing is to be able to retrieve and synchronize information that is
meant for simultaneous processing and presentation; it's not just
something pointlessly done for its own sake. I'm against any features
that have no use except for helping people do stupid things like
this..

>   that was suggested by rich and would allow seeking with stored
>   broadcasts even if some streams had only rare keyframes.

While I did at one point suggest multiple back_ptrs, it was never
intended for such stupid use. We later discovered that we could get
adequate results with just a single back_ptr, so I dropped the
recommendation.

Rich