[MPlayer-dev-eng] Nut and B frames

[D Richard Felker III]

On Wed, Apr 28, 2004 at 12:00:48AM +0200, Michael Niedermayer wrote:
> > It increases filesize, 
> not necessarily, it depends upon how dts are stored
> dts will normally be last_dts + 1

Then it's useless to code it, right? :)

> > and dts isn't a  
> > useful quantitity to have (you only need decode _order_, not the
> > timestamp, and order is implied by the order frames are stored in the
> > file).
> >
> > IMO the decision is between choice #1 (storing frames in display order
> s/display/decode/ ?!

Yes, my bad. I just said the wrong thing.

> > with non-monotone pts and having some half-working semi-monotonicity
> > rules to ensure decent interleaving) or choice #3 (my new proposal
> > with the zero-size packets for pts). Not sure which is better. Do you
> > have any comments (good or bad) on #3?
> i dont like #3, its the well known hack divx and xvid use to store b frames in 
> avi, but thats not a good argument to reject it, but maybe i found a case 
> which #3 cant handle (see end of mail)
> 
> btw, heres some more idiot proof code to calculate dts from pts
> ----
> if(start, seeking, ...)
>     for(i=0; i<decoder_delay; i++)
>         pts_list[i]= -1;
> 
> min_pts= pts;
> min_i=-1;
> for(i=0; i<decoder_delay; i++){
>     if(pts_list[i] < min_pts){
>         min_pts= pts_list[i];
>         min_i = i;
>     }
> }
> 
> dts= min_pts;
> if(min_i>=0) pts_list[min_i]= pts;

Yes, this serves as a proof that dts-order coding plus a "delay" field
in the stream header is sufficient to make crappy players work. :)

> ----
> type&pts: I0 P3 B1 B2 P4 P6 B5
> list       -  0  3  3  3  4  6
> dts        -  0  1  2  3  4  5
> 
> type&pts: I0 P3 P6 B1 B2 P9 B4 B5 ..
> list      -- -0 30 36 36 36 96 96
> dts        -  -  0  1  2  3  4  5
> 
> 2 level bframe prediction I0->B2<-P4 I0->B1<-B2, ...
> type&pts: I0 P4 B2 B1 B3 P8 B6 B5 B7 ...
> list      -- -0 40 42 42 43 48 68 68
> dts        -  -  0  1  2  3  4  5  6
> 
> and now with #3 
> type&pts: I0 Px B1 B2 .3 P4 Px B5 .6
> 
> type&pts: I0 Px Px B1 B2 .3 Px B4 B5 .6 ..
> 
> type&pts: I0 Px B2 B1 B3 .4 Px B6 B5 B7 .8 ...
> hmm wrong ...
> rich, do u see a way this could be done with #3 ?

The notation is confusing now because even tho the frames don't always
have pts attached directly to them, _we_ should know the pts for
writing examples, to show which order our muxer stored the frames in.
:) So let's rewrite frames as "tmn" where t=type, m=pts (actual time
the frame should be shown), n=coded_pts:

type&pts: I00 P3x B11 B22 .33 P44 P6x B55 .66

type&pts: I00 P3x P6x B11 B22 .33 P9x B44 B55 .66 ..

And now the corrected example 3:

type&pts: I0 P4x B2x B11 .22 B33 .44 P8x B6x B55 .66 B77 .88 ...

And back to your notation:

type&pts: I0 Px Bx B1 .2 B3 .4 Px Bx B5 .6 B7 .8 ...

Notice that the m's are always monotone and can be used for the
purpose of interleaving. Everything else just gets filled in according
to order of dependence (same order as encoder output).

Maybe your complaint is that the codec won't know _which_ "pending"
frame to output for one of the t=. points. But IMO this isn't
possible. The codec always has to know which frame it's going to
output next, independent of the container...

Rich