[MPlayer-dev-eng] Nut and B frames

[Michael Niedermayer]

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

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

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

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en