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