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