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