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

[Michael Niedermayer]

Hi

On Sat, Dec 31, 2005 at 06:37:35PM +0200, Oded Shimon wrote:
[...]
> > [...]
> > >  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
> 
> Hmm, well, not necessarily, you never know with weird codecs...

if rich says ok to this iam fine with it too, though i doubt we will ever
see such a codec and theres some risk of contradictionary streams from brokrn
muxers (non keyframe EOR or non zero size)


> 
> > > +    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?
> 
> Seems you misunderstand EOR - It's not "end of stream" (old name was bad), 
> it's "end of relavence".
> for ex., a subtitle stream and there's currently no subtitle showing, 
> that's EOR. The stream is completely irrelavent for presenting this part of 
> the video. Basically it's any "gap" in a stream.
> 
> back_ptr's are zero because they are just not interesting, the stream is 
> completely "irrelavent".

ok as long as seeking works with this, i mean that

syncpoint keyframe_st2 EOR_st1 syncpoint 
and seeking to keyframe_st2 will still be able to find the previous keyframe
for st1


> 
> > [...]
> > 
> > iam not sure if i like the mts stuff ...
> 
> It has one big flaw IMO, it makes the muxer knowing the future manditory. 
> Or at the very least a smart muxer-caller.
> 
> I decided with Rich that the API for the muxer will be that you MUST pass 
> it the mts of a frame whenever you pass it a frame. Meaning either the 
> caller has to be smart, or it has to use the high level reorderer, which 
> always uses buffering.
> MTS however is still the most correct way to store the data IMO... old dts 
> method is wrong (depends on decode_delay), and MN rule is insufficient.

i still vote for the dts rule as i fail to see any serious problem with it

[...]

-- 
Michael