List Info

Thread: Info packets in NUT stream (spec bugs?)




Info packets in NUT stream (spec bugs?)
user name
2006-11-04 13:53:13
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
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel
[1]

about | contact  Other archives ( Real Estate discussion Medical topics )