[MPlayer-dev-eng] Nut and B frames

[D Richard Felker III]

On Tue, Apr 27, 2004 at 07:22:17PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Tuesday 27 April 2004 18:43, D Richard Felker III wrote:
> > On Tue, Apr 27, 2004 at 12:28:28PM -0400, D Richard Felker III wrote:
> > > I'm still not sure how to write down the rule for the muxer, tho...
> > > The basic principle is that timestamps should be monotone except that
> > > reference frames needed should be stored in decode order. But the
> > > rule gets complicated when you have multiple streams with out-of-order
> > > frames... :)
> >
> > Actually there's one other solution I sort of like. It wastes a small
> > amount of space, but it seems more correct...
> >
> > For out-of-order frames, mux the frame in decode order with NO pts.
> > Then include a dummy frame (0 byte) at the presentation time for the
> > frame. This dummy frame just means "display the next frame the codec
> > outputs".
> hmm, iam starting to really hate b frames

You'll hate them more once you see the patch I just submitted... ;)

> anyway, theres yet another possibility, just additionally store reordered pts 
> if the stream contains b frames, that way we can
> 1. enforce monotonicity
> 2. support push style demuxers
> 3. store frames in decoding order as required by the mpeg specs

Is reordered pts the same thing as dts (decode timestamp)?

> how to store reordered pts?
> possibility 1: index into array of previously decoded pts values 
> possibility 2: like pts
> possibility 3: simply the difference to the pts
> possibility 4: like 3 but exchange how pts and reordered pts are stored

I don't like this proposal. It increases filesize, 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
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?

Rich