[MPlayer-dev-eng] Lots of stuff for NUT

[Michael Niedermayer]

Hi

On Sat, Dec 31, 2005 at 04:27:59PM +0200, Oded Shimon wrote:
[...]
> @@ -221,12 +229,37 @@
>  index:
>      index_startcode                     f(64)
>      packet header
> -    stream_id                           v
>      max_pts                             v
> -    index_length                        v
> -    for(i=0; i<index_length; i++){
> -        index_pts                       v
> -        index_position                  v
> +    syncpoints                          v
> +    for(i=0; i<syncpoints; i++){
> +        syncpoint_pts                   v
> +        syncpoint_pos_div8              v
> +    }
> +    for(i=0; i<stream_count; i++){
> +        type                            v
> +        j=0
> +        if (type) while (j<syncpoints){
> +            repeat                      v
> +            b=repeat&1
> +            repeat=(repeat>>1)+1
> +            for(k=0; k<repeat; k++){
> +                syncpoint[j+k].stream[i].back_ptr= syncpoint[j-b].pos_div8
> +            }
> +            j+= repeat
> +        } else while (j<syncpoints) {
> +            repeat                      v
> +            repeat++
> +            b=repeat&1
> +            repeat=repeat>>1
> +            for(k=0; k<repeat; k++){
> +                syncpoint[j+k].stream[i].back_ptr= syncpoint[j+k-b].pos_div8
> +            }
> +            if (!repeat) {
> +                syncpoint[j].stream[i].back_ptr= syncpoint[j-1].stream[i].back_ptr
> +                j++
> +            }
> +            j+= repeat
> +        }

do we really need to allow a backptr to point to the current syncpoint? what
do we loose if we would point to the previous?


[...]

> +    syncpoints MUST be placed immediately before a keyframe if more
> +    than max_distance passed since previous keyframe of the same stream,
> +    unless the timestamp to be set for this syncpoint is identical to the
> +    last syncpoints's timestamp. In which case, the syncpoint is to be put
> +    immediately BEFORE the timestamp will change. (So it will still have
> +    the same timestamp)

i dont like having multiple syncpoints with the same timestamp, this is going
to cause problems iam pretty sure


[...]
>  flags[frame_code]
> -    first of the flags from MSB to LSB are called KD
> -    if D is 1 then data_size_msb is coded, otherwise data_size_msb is 0
> -    K is the keyframe_type
> -        0 -> no keyframe,
> -        1 -> keyframe,
> -    flags=4 can be used to mark illegal frame_code bytes
> -    frame_code=78 must have flags=4
> -    Note: frames MUST NOT depend(1) upon frames prior to the last
> -          frame_startcode
> -    Important: depend(1) means dependency on the container level (NUT) not
> -    dependency on the codec level
> +    Bit  Name             Description
> +      1  data_size_msb    if set, data_size_msb is at frame header,
> +                          otherwise data_size_msb is 0
> +      2  more_flags       if set, stream control flags are at frame header.
> +      4  invalid          if set, frame_code is invalid.
> +
> +    frame_code=78 ('N') MUST have flags=64
> +
> +stream_flags
> +    stream_flags is "stream_flags[frame_code] | coded_stream_flags"
> +
> +    Bit  Name             Description
> +      1  is_key           if set, frame is keyframe
> +      2  end_of_relavence if set, stream has no relavence on
> +                          presentation until next frame. (EOR)
> +
> +    EOR frames MUST be zero-length and must be set keyframe. EOR is unset

hmm, this is somewhat redundant, zero byte keyframes cant occur, so 
zero byte keyframes could mean EOR


> +    by the first frame following the EOR of the same stream.

and what is this good for? why should we allow anything to follow the
end of a stream?


> +    When EOR is set, all back_ptr's for this stream are set to zero.
> +    All streams SHOULD end with EOR.

how exactly do you seek if the back_ptrs dont point to the previous keyframe?

[...]

iam not sure if i like the mts stuff ...

[...]

-- 
Michael