[MPlayer-dev-eng] NUT (informal) proposal, based on discussions

[Rich Felker]

On Fri, Jan 20, 2006 at 09:53:18AM +0200, Oded Shimon wrote:
> > one of us will send an updated proposal soon.
> 
> Here it is..
> 
> step-4:
>   add EOR
>   add coded stream flags
>   rearrange header a little bit - the actual changes are that tmp_mul and 
>   tmp_pts are after tmp_stream, and everything has a default value.

Alright.

> step-5:
>   change goals slightly..
>   max_index_distance removed
>   index changed to combination of syncpoint index and pts for keyframes, 
>   using ideas by michael and myself
>   syncpoint still single back_ptr and pts, however back_ptr is changed - 
>   points to most correct keyframe, not most recent.

All good. :)

>   syncpoint timestamp is max(last_dts)

Just specifying that it should be greater than all previous dts and
less than all future pts should be fine.

BTW the spec needs to address the boundary issues. One direction is
supposed to include equality for all the ordering rules, i.e.
half-open intervals.

> whats left:
>   info streams, how do they deal with EOR, back_ptr, etc.

Yes, I think (hope) this is entirely straightforward.

>   index repetition (atleast the option for it)

OK, no objection as long as whenever there's an index at all, there
must be an index at the end (so demuxers can reasonably omit searching
for it anywhere else).

> I see in my old notes something about "fourcc for PCM", as in, PCM audio 
> can't really be stored in NUT easily because you need byte order etc., and 
> there is no defined fourcc for PCM's that tells that info, but I guess 
> that's not a really worry for the spec...

IMO the issue of "what is a fourcc?" is relevant for the spec,
especially for audio where fourcc is not so well-established. Michael,
do you have opinions on what we should do for codec tags?

The obvious windows idiot answer would be to store a WAVEFORMATEX
"codec header" for pcm audio, but IMO this is not acceptable.

> I want to test the index spec (<100kb might be a lie, but i doubt it), and 
> commit step-4, step-5 and cosmetic... Is anyone against?

See below. Overall, no, not against it. But some minor things first..

> BTW, does anyone have a good idea for efficient but simple data structure 
> for decoded index?... The naive way requires 
> streams*syncpoints*sizeof(uint64_t) memory, which is too much. (5mb of 
> ram?..) Any other idea I can think of requires some complication for 
> just using the values or changing them... (I still want the ability to 
> dynamically build the index while playing)

I'll let you know if I think of something good.

> BTW2, with linear interpolation, for a 700mb file, seeks average to 4-10 
> underlying seeks for the binary search.

I wonder if this can be improved.

> @@ -302,6 +311,11 @@
>      one keyframe for each stream lies between the syncpoint to which
>      real_back_ptr points, and the current syncpoint.
>  
> +    A stream where EOR is set is to be ignored for back_ptr.
> +
> +    Note: back_ptr can be zero if there is only a single relavent stream
> +    and has a keyframe immediately following the syncpoint.
> +

I thought we said zero back_ptr was to be dropped. I'm certainly
against wording it as "can" -- either it must be zero, or it can never
be zero.

>  Error resistant
>      seeking / playback without an index
> -    headers & index can be repeated
> +    headers can be repeated
>      damaged files can be played back with minimal data loss and fast
>      resync times

Don't change this; we're about to change it back I thought..

>  global_key_pts
>      After a syncpoint, last_pts of each stream is to be set to:
>      last_pts[i] = convert_ts(global_key_pts, timebase[stream], timebase[i])
>  
> +    global_key_pts MUST be the highest dts across all streams for all
> +    frames before the syncpoint.
> +

Greater than [or equal to] all prior dts. No need to specify it any
more exactly if we are using MN rule, unless you have a good reason.

> +syncpoint_pos_div8
> +    offset from begginning of file to up to 7 bytes before the syncpoint
> +    referred to in this index entry. Relative to position of last
> +    syncpoint.

Clarify the div8 stuff slightly.

>  index_ptr
> -    Length in bytes from the first byte of the first index startcode
> -    to the first byte of the index_ptr. If there is no index, index_ptr
> -    MUST NOT be written.
> +    Length in bytes from the first byte of the index startcode to the first
> +    byte of the index_ptr. If there is no index, index_ptr MUST NOT be
> +    written.

Mention that if a candidate index_ptr points outside the file or if
the data it points to is not index_startcode, then it should not be
interpreted as index_ptr. :)

Rich