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