[NUT-devel] Patch for info frames

[Rich Felker]

On Sat, Feb 25, 2006 at 09:03:49PM +0200, Oded Shimon wrote:
> Comments...
> 
> - ods15

> Index: DOCS/tech/mpcf.txt
> ===================================================================
> RCS file: /cvsroot/mplayer/main/DOCS/tech/mpcf.txt,v
> retrieving revision 1.113
> diff -u -r1.113 mpcf.txt
> --- DOCS/tech/mpcf.txt	25 Feb 2006 18:51:46 -0000	1.113
> +++ DOCS/tech/mpcf.txt	25 Feb 2006 19:03:05 -0000
> @@ -637,9 +637,15 @@
>      s= chapter_start % stream_count
>      timestamp= chapter_start / stream_count
>      timestamp of start of chapter in timebase of stream 's'.
> +    In info streams, if chapter_start is zero, chapter_start is the pts of
> +    the first unrepeated info frame.
>  
>  chapter_len
>      Length of chapter in same timebase of chapter_start.
> +    In info streams, if chapter_len is zero, chapter_len is the pts of
> +    the first EOR or info frame with a different chapter_id in the same
> +    info stream, minus chapter_start.
> +    In info streams, if chapter_start is zero, chapter_len MUST be zero.
>  
>  type
>      for example: "UTF8" -> string or "JPEG" -> JPEG image
> @@ -741,6 +747,12 @@
>  
>  Info frames can be used to describe the file or some part of it (chapters)
>  
> +The pts of an info frame MUST be >=chapter_start and <=chapter_start+len
> +(Compared using compare_ts)
> +
> +If an info stream contains an info frame for chapter X then it MUST contain
> +an info frame with pts==chapter_start
> +
>  Info SHOULD be stored in global packets instead of info streams/frames if
>  possible, and the amount of data is not large.

I'm ok with this patch, with one additional pair of requirements:

1. If chapter_start is coded, then a copy of the info frame must
   appear at the timestamp coded in chapter_start.
2. No frame with a different chapter_id (or EOR) may appear between
   chapter_start and chapter_start+len.

With the addition of these constraints, it's always possible to decode
with the stream-style behavior, but when chapter_len is known it
provides extra information in advance (and may improve error
recovery in case a frame is lost).

BTW, one more thing: chapter_start==0 is a weird way to omit the field
since 0 is also a valid pts. 0 is not a valid value for chapter_start
unless pts==0 as well, so this may be ok, but there may be problems if
a packet is lost.. What about just always requiring chapter_start to
be coded (and equal to the pts of the first copy) and making
chapter_len the only optional field?

Rich