[NUT-devel] Info packets in NUT stream (spec bugs?)

[Michael Niedermayer]

Hi

On Sun, Nov 05, 2006 at 09:48:46AM +0200, Oded Shimon wrote:
> On Sun, Nov 05, 2006 at 12:19:53AM +0100, Michael Niedermayer wrote:
> > On Sun, Nov 05, 2006 at 12:02:04AM +0200, Oded Shimon wrote:
> > > On Sat, Nov 04, 2006 at 10:47:45PM +0100, Michael Niedermayer wrote:
> > > > also for the case of realtime streams where song info is updated at the
> > > > song start, well there must be a main header there anyway or you cant
> > > > start listening ...
> > > > the exception would be if the main header is transmitted out of band with
> > > > SDP or similar but then the info packets could as well be transmitted
> > > > out of band instead of blindly sending them duplicated a few times ...
> > > 
> > > Why would i need to repeat the main headers just for a song change? it 
> > > involves no codec change or anything else (which is illegal in NUT 
> > > anyway), just a change of songs, which means nothing but a change of 
> > > metadata... This is a radio, the main headers are only given for you once 
> > > at connect (which btw should carry the metadata of the _current_ song), 
> > > but the metadata can change frequently, so you need to send new info 
> > > packets, no need to send with it the entire bloated vorbis header...
> > 
> > as you send a client specific stream (mainheaders just at a specific start)
> > you can as well send the mainheaders and info out of band IMHO, that way
> > they are not part of the nut file and the restrictions wont apply IMHO
> > 
> > mainheaders are critical (should be transmited over a reliable protocol
> > like TCP) the normal remaning stream could as well be transmitted over
> > UDP with retransmits only of non B frames or retransmits depending on
> > other parameters (no use in retransmitting data if its in the clients
> > past and not needed for prediction of future frames)
> > 
> > also nut is no network protocol, i have my doubts it will be used raw 
> > in such a streaming case ...
> 
> It could, there's no real reason you can't just TCP NUT over some simple 
> protocol. Oh no, I'm turning into Ivan :)
> 
> > this is more something for nut-np ...
> 
> I think it would be a bit weak if it would be impossible to send new info 
> data in NUT.. Though I do see the logic that it is a network thing instead 
> of a file thing and should be out of band... I'm a bit torn on this 
> issue...
> 
> > the big problem with simply allowing arbitrarily placed info is that it 
> > makes the info useless for the normal nut file case as the info cannot be
> > found its like a dvd with chapters but the information about where the
> > chapters begin is stored at the begin of the chapters, you end up with
> > a O(n) search ...
> > so ive some concerns with just saying its ok for streaming, as that
> > leads to nut files laying around which are encoded for streaming ...
> 
> The proposal I had for this is - info packets not written after main 
> headers are only allowed in real time streaming, and must have 
> chapter_id!=0, and any info packets written after main headers, both in 
> file and in streaming scenario, MUST be repeated together with all main 
> headers. No demuxer would have to search anything past main headers, any 
> info packets given during demuxing is "information update". In the file 
> scenario, all info must be written after the main headers, so no searching 
> necessary.

hmm, rich what is your oppinion about that? iam unsure if iam against it
or not ...

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

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is