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

[Oded Shimon]

On Fri, Nov 10, 2006 at 08:57:23AM +0200, Oded Shimon wrote:
> On Mon, Nov 06, 2006 at 01:44:19PM +0100, Michael Niedermayer wrote:
> > On Mon, Nov 06, 2006 at 10:56:57AM +0200, Oded Shimon wrote:
> > > On Sun, Nov 05, 2006 at 09:32:44PM +0200, Oded Shimon wrote:
> > > > On Sun, Nov 05, 2006 at 07:07:22PM +0100, Michael Niedermayer wrote:
> > > > > On Sun, Nov 05, 2006 at 09:48:46AM +0200, Oded Shimon wrote:
> > > > > > On Sun, Nov 05, 2006 at 12:19:53AM +0100, Michael Niedermayer wrote:
> > > > > > > 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 ...
> > > > > > 
> > > > > > The proposal I had for this is - info packets not written after main 
> > > > > > headers are only allowed in real time streaming, and must have 
> > > > > > chapter_id!=0, and any info packets written after main headers, both in 
> > > > > > file and in streaming scenario, MUST be repeated together with all main 
> > > > > > headers. No demuxer would have to search anything past main headers, any 
> > > > > > info packets given during demuxing is "information update". In the file 
> > > > > > scenario, all info must be written after the main headers, so no searching 
> > > > > > necessary.
> > > > > 
> > > > > hmm, rich what is your oppinion about that? iam unsure if iam against it
> > > > > or not ...
> > > > 
> > > > - ods15
> > > 
> > > Objections? Commit? 48 hour notice from now.
> > 
> > i object until i heard a comment from at least rich, comments from
> > everyone else are of course welcome too
> 
> This is a new proposal: Basically identical to the previous one, only info 
> packets SHOULD NOT appear "in the wild" in non-realtime-streams instead of 
> MUST NOT. Making the distinction between file and realtime streams less 
> strict. Demuxers still SHOULD NOT search for info packets anywhere except 
> after the main headers. I think this is most clean...
> 
> Comments?

Repost. ... 48 hour notice ...

> Index: nut.txt
> ===================================================================
> --- nut.txt	(revision 20666)
> +++ nut.txt	(working copy)
> @@ -180,11 +180,15 @@
>              packet_header, index_packet, packet_footer
>          }
>          if (!eof) while(next_code != main_startcode){
> -            if(next_code == syncpoint_startcode){
> -                packet_header, syncpoint, packet_footer
> +            packet_header, syncpoint, packet_footer
> +            do{
> +                frame
> +            }while(next_code == framecode);
> +            reserved_headers
> +            while(next_code == info_startcode){
> +                packet_header, info_packet, packet_footer
> +                reserved_headers
>              }
> -            frame
> -            reserved_headers
>          }
>      }
>  
> @@ -836,9 +840,15 @@
>  Info:
>  -----
>  
> -If a info packet is stored anywhere then a muxer MUST also store an identical
> +All info packets stored after a main header set MUST also have an identical
>  info packet after every main-stream-header set
>  
> +All info packets not stored after a main header set MUST have
> +chapter_id!=0 .
> +
> +Info packets SHOULD be written after main header sets in non realtime
> +streams.
> +
>  If a demuxer has seen several info packets with the same chapter_id and
>  stream_id then it MUST ignore all but the one with the highest position in
>  the file

- ods15