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

[Michael Niedermayer]

Hi

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:
> > Hi
> > 
> > On Sat, Nov 04, 2006 at 03:53:13PM +0200, Oded Shimon wrote:
> > > hmm, several bugs found in spec?
> > [...]
> > > > the structure of a undamaged file should look like the following,
> > > > [...]
> > > > file:
> > > >     file_id_string
> > > >     while(!eof){
> > > >         packet_header, main_header, packet_footer
> > > >         reserved_headers
> > > >         for(i=0; i<stream_count; i++){
> > > >             packet_header, stream_header, packet_footer
> > > >             reserved_headers
> > > >         }
> > > >         while(next_code == info_startcode){
> > > >             packet_header, info_packet, packet_footer
> > > >             reserved_headers
> > > >         }
> > > >         if(next_code == index_startcode){
> > > >             packet_header, index_packet, packet_footer
> > > >         }
> > > >         if (!eof) while(next_code != main_startcode){
> > > >             if(next_code == syncpoint_startcode){
> > > >                 packet_header, syncpoint, packet_footer
> > > >             }
> > > >             frame
> > > >             reserved_headers
> > > >         }
> > > >     }
> > > 
> > > Is it supposed to be impossible to write an info packet without writing an 
> > > entire main header set?
> > 
> > the text above would suggest so ...
> > is there a problem with this?
> > does it not match something which was agreed upon? (no i dunno)
> > 
> > the possibility to write info packets anywere was removed in
> > r16507
> > at that time we still had info streams, which where later droped
> 
> There were too many info flamewars for me to remember :)
> 
> > 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 ...

this is more something for nut-np ...


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

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