[MPlayer-dev-eng] NUT, what's left

[Rich Felker]

On Sat, Sep 17, 2005 at 10:06:20AM +0200, Michael Niedermayer wrote:
> see attached patch

:))))))))

> > 2. DTS method (MN rule or MTS?)
> 
> not sure, this needs some more thought, but i dont have time now for that now

Yes.

> > 3. info packets... how should they be used at all
> 
> see attached patch

:)))))))))))))))))))))))))))))

> > 4. subtitles, i want a more strict definition for them.. (they require info 
> >    packet?)
> > 5. what should max_index_distance be, Rich says 32k is too small and should 
> >    be 512k.
> 
> i dont see why, so i disagree

Index is huge with every audio frame indexed. :(
BTW I have a new idea whereby it might be _easier_ to just have one
index rather than per-stream indices. It relates to syncpoints and
backpointers, but doesn't require searches. I'll post something soon
when I make sure it makes at least some sense..

> > 6. possibly remove the "GPL" code in there as that seems to scare some very 
> >    weird people (or just make it public domain).
> 
> do we care about these people ;) well i wont object changing the 10 line
> example in there to public domain if everyone thinks its a good idea

Yes, sadly we do. These are the people working for companies that we
want to support NUT (in their hardware, etc.)...

> > 7. Zero byte frames in the end.
> 
> i dont care

IMO zero byte frame should indicate end (duration) of previous frame
and no new data. This can be used for end of file (final duration) and
for signaling no data in subtitle streams to prevent backpointers from
being insanely far back.

> > 8. Anything else?
> 
> probably :)

:)))))

> @@ -255,13 +254,11 @@
>  				other_stream_header
>  		}
>  		while(next_code != main_startcode){
> +			if(next_code == frame_startcode)
> +				sync_point
>  			if(next_code == info_startcode)
> -				info_packet
> -			else{
> -				if(next_code == frame_startcode)
> -					sync_point
> -				frame
> -			}
> +				info_startcode	f(64)
> +			frame
>  		}

I'm a bit confused about how this matches the below description of how
info frames are stored..

> +back_ptr
> +	pointer to the latest frame, for which there is at least one
> +	keyframe prior to the global_timestamp in every stream
> +

This does not work. The backpointer must point to a syncpoint;
otherwise it's impossible to parse timestamps without linear searching
backwards for the previous syncpoint.

>  file_id_string
>  	"nut/multimedia container\0"
>  
> @@ -331,6 +332,8 @@
>  	1	audio
>  	2	subtiles
>  	3	metadata
> +	4	userdata
> +	in metadata streams each frame contains exactly one info frame

Nice addition/clarification!

> @@ -450,7 +453,7 @@
>  	stream, into which the current pts is inserted and the element with
>  	the smallest value is removed, this is then the current dts
>  	this buffer is initalized with decode_delay -1 elements
> -	all frames with dts == timestamp must be monotone, that means a frame
> +	all frames except repeated frames must be monotone, that means a frame
>  	which occurs later in the stream must have a larger or equal dts
>  	than an earlier frame

This still needs some clarification, but we need to decide on the rule
first anyway I guess.

> -info packets which describe the whole file or individual streams/tracks MUST be
> -placed before any video/audio/... frames
> +info frames which describe the whole file or individual streams/tracks MUST be
> +placed at least immedeatly after each repeadted set of the stream headers and
> +before the following video/audio/userdata/... frames. Such info frames must be
> +like the main and stream headers always identical

:)))))))

> -		Info packets
> -the info_packet can be repeated, and can also contain different names & values
> -each time, but only if the time is different
> -Info packets can be used to describe the file or some part of it (chapters)
> -
> -info packets SHOULD be placed at the start of the file at least for realtime
> -streaming info packets will normally be transmitted when they apply for
> -example, the current song title & artist of the currently shown music video
> +		Info frames
> +a info frame can be repeated, but must then be exactly identical
> +Note, such repeated frames can be detected by their pts difference of 0
> +Info frames can be used to describe the file or some part of it (chapters)

:)))))))))))))))

Rich