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

[Michael Niedermayer]

On Sun, Feb 03, 2008 at 10:27:21PM -0500, Rich Felker wrote:
> 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..

Or in other words you dont want nut to be useable in broadcast environments.


> 
> >   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. 

No, it was intended for an even more stupid one ;)
That is to seek in files where streams have rare and randomly placed
keyframes, that is you cant seek while demuxing and decoding all streams.


> We later discovered that we could get
> adequate results with just a single back_ptr, so I dropped the
> recommendation.

Yes and i fully agree that multiple back_ptrs are unneeded normally.
The broadcast case is an exception though where they could be usefull.

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- 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/fdb8f602/attachment.pgp>