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

[Oded Shimon]

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.

- ods15