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

[Oded Shimon]

hmm, several bugs found in spec?

from spec:
> If a info packet is stored anywhere then a muxer MUST also store an identical
> info packet after every main-stream-header set

This is nonsense in real time streaming, isn't it?.. In real time 
streaming, the only rule i suggest there should be is that after a 
main-header set, there should be all global info packets (chapter_id==0), 
and info packets applying to the current chapter. (e.g., if you joined in 
the middle of a song, you should get the info packet telling about the 
song)

> info_packet:
>     stream_id_plus1                     v
>     chapter_id                          v
>     chapter_start                       t
>     chapter_len                         v
> [...]
> chapter_id
>     Id of chapter this packet applies to. If zero, packet applies to whole
>     file. Positive chapter_id's are real chapters and MUST NOT overlap.
>     Negative chapter_id indicate a sub region of file and not a real
>     chapter. chapter_id MUST be unique to the region it represents.

Ahem, negative?.. 'v' unsigned vlc ...

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


And I have an API question for libnut demuxer:
for the case of info headers after main headers, I plan on looking for 
them only once and give them to the caller together with the main header 
information, but what should I do for the case of info packets found in 
the wild? optional callback function?

- ods15