[MPlayer-dev-eng] [PATCH] fix reordering

[Dan Oscarsson]

sön 2010-07-11 klockan 12:02 +0200 skrev Reimar Döffinger:
> On Sun, Jul 11, 2010 at 11:06:39AM +0200, Dan Oscarsson wrote:
> > > Also, I really can't see what it should change, correct_pts is not
> > > set for demux_ts and AFAIK it does not work with it.
> > 
> > It is necessary to set -correct-pts for all LATM DVB-T recordings I have
> > and work fine without my patch - if you do not seek in the file. If you
> > seek, the reorder code fails - normally missing one out of four frames.
> > With my patch it work all the time.
> > 
> > If you do not like to fix it the way my patch does - what shall we do to
> > fix it? I do not want to try to understand the seek code in demux_ts.c
> > to get the seek to work, when it can be fixed so easily in dec_video.c.
> 
> First someone could test if it actually does break someting or not (PAFF
> with -demuxer lavf).

Do you have a PAFF sample that I could try it with?

> Then the need to use -correct-pts should be fixed.

You mean that demuxer/decoder should do the reordering instead?

> Then of course the missing timestamps from the ts demuxer should be
> corrected, since that is going to cause issues either way.
> Then the -correct-pts code should be investigated why it fails to recover
> even after a longer time and if that can be fixed/autodetected.

The code that handles reodering of pts values gets it wrong due to
ignoring one value that should be handled. Looking at what happens I see
call to decode_video with:

 call    pts
    1      -       noimg
    2      x       noimg
    3      x       noimg
    4      x       noimg
    5      x       img
    6      x       img
    7      x       img
        etc

where x means valid pts and noimg means mpvdec->decode returned NULL.
get_current_video_decoder_lag returns 4

By ignoring storing the first frame with invalid pts in the buffer of
pts values to be reordered, you have too few values buffered when first
frame is returned for display. There should be one more.
When call 5, the frame that arrives could be frame 1 whose value was
discarded. So it will use one of the pts values from call 2-5.

And it will never recover as decode do not return noimg later. Instead
there will continue to be one value less than needed in buffer.

   Dan