Re: [xine-devel] DV Color Fixed

[Bill F. <bil...@mi...>]

Hi again,

On Mon, 3 Feb 2003, I wrote:

> On Mon, 3 Feb 2003, Miguel Freitas wrote:
> 
> > > I've narrowed it down to working fine on 7 Jan 18:00 (my time EST), and
> > > broken six hours later on 8 Jan 0:00.  A gzipped diff between
> > > the two is attached.  I've looked at it for a while, but haven't been
> > > able to find anything obvious on my own so far.
> > 
> > i see nothing here, just the unknown codec reporting stuff.
> > 
> > if you are really sure this is related, you will need to narrow it down
> > further. i would suggest you to apply only the ffmpeg and xine-engine
> > parts, for example. i don't see how other decoders/demuxers could cause
> > any trouble to rawdv.
> 
> OK, I did as you suggested, and it still fails when the attached diff
> is applied to the working 7 Jan 18:00 EST CVS version, and I still haven't
> figured it out.

Well after some more sleuthing, my conclusion is that there's something
major wrong with the xine-engine changes that were made on 7/8 Jan that
are given in the attached diff.

First, before anything else, I had to fix a bug in libffmpeg/xine_decoder.c.

--- .orig/xine_decoder.c        Tue Feb  4 01:08:28 2003
+++ .mod/xine_decoder.c Tue Feb  4 01:05:45 2003
@@ -466,6 +466,9 @@
          if (this->size>0)
            memmove (this->buf, &this->buf[offset], this->size);

+         if( codec_type == BUF_VIDEO_DV && this->skipframes ) {
+           this->skipframes -= 2;
+         }
          return;
        }

Without this change, once the decoder got behind and set this->skipframes,
it would never reset it, resulting in all the remaining input being
consumed but nothing more ever getting displayed.  Perhaps the if test
should only be testing this->skipframes, but at the moment i was only
concerned with correcting the rawdv behavior.  It's also odd to decrement
this->skipframes by 2, but the debugging output always showed skipframes
to be even, and empirical testing demonstrated that decrementing by
only 1 didn't result in as good video playback (perhaps there's a bug
in the img->draw function causing skipframes to be incremented twice).

After adding some debug printout, the good case before the problematic
change does in fact look good:

ffmpeg: got a picture
ffmpeg: got a picture
ffmpeg: got a picture
ffmpeg: got a picture
ffmpeg: got a picture
ffmpeg: got a picture
ffmpeg: got a picture
ffmpeg: got a picture
ffmpeg: got a picture
ffmpeg: got a picture

There were no skipped frames and there was still about 20% of
idle CPU time left.

But after the change:

ffmpeg: got a picture
metronom: video jump
ffmpeg: didn't get a picture, this->skipframes = 12
ffmpeg: didn't get a picture, this->skipframes = 10
ffmpeg: didn't get a picture, this->skipframes = 8
ffmpeg: didn't get a picture, this->skipframes = 6
ffmpeg: didn't get a picture, this->skipframes = 4
ffmpeg: didn't get a picture, this->skipframes = 2
ffmpeg: got a picture
ffmpeg: didn't get a picture, this->skipframes = 20
ffmpeg: didn't get a picture, this->skipframes = 18
ffmpeg: didn't get a picture, this->skipframes = 16
ffmpeg: didn't get a picture, this->skipframes = 14
ffmpeg: didn't get a picture, this->skipframes = 12
ffmpeg: didn't get a picture, this->skipframes = 10
ffmpeg: didn't get a picture, this->skipframes = 8
ffmpeg: didn't get a picture, this->skipframes = 6
ffmpeg: didn't get a picture, this->skipframes = 4
ffmpeg: didn't get a picture, this->skipframes = 2
ffmpeg: got a picture
metronom: video jump
ffmpeg: didn't get a picture, this->skipframes = 12
ffmpeg: didn't get a picture, this->skipframes = 10
ffmpeg: didn't get a picture, this->skipframes = 8
ffmpeg: didn't get a picture, this->skipframes = 6
ffmpeg: didn't get a picture, this->skipframes = 4
ffmpeg: didn't get a picture, this->skipframes = 2
ffmpeg: got a picture
ffmpeg: didn't get a picture, this->skipframes = 20
ffmpeg: didn't get a picture, this->skipframes = 18
ffmpeg: didn't get a picture, this->skipframes = 16
ffmpeg: didn't get a picture, this->skipframes = 14
ffmpeg: didn't get a picture, this->skipframes = 12
ffmpeg: didn't get a picture, this->skipframes = 10
ffmpeg: didn't get a picture, this->skipframes = 8
ffmpeg: didn't get a picture, this->skipframes = 6
ffmpeg: didn't get a picture, this->skipframes = 4
ffmpeg: didn't get a picture, this->skipframes = 2
ffmpeg: got a picture
metronom: video jump
ffmpeg: didn't get a picture, this->skipframes = 12
ffmpeg: didn't get a picture, this->skipframes = 10
ffmpeg: didn't get a picture, this->skipframes = 8
ffmpeg: didn't get a picture, this->skipframes = 6
ffmpeg: didn't get a picture, this->skipframes = 4
ffmpeg: didn't get a picture, this->skipframes = 2
ffmpeg: got a picture
ffmpeg: didn't get a picture, this->skipframes = 20
ffmpeg: didn't get a picture, this->skipframes = 18
ffmpeg: didn't get a picture, this->skipframes = 16
ffmpeg: didn't get a picture, this->skipframes = 14
ffmpeg: didn't get a picture, this->skipframes = 12
ffmpeg: didn't get a picture, this->skipframes = 10
ffmpeg: didn't get a picture, this->skipframes = 8
ffmpeg: didn't get a picture, this->skipframes = 6
ffmpeg: didn't get a picture, this->skipframes = 4
ffmpeg: didn't get a picture, this->skipframes = 2
ffmpeg: got a picture
metronom: video jump

This pattern repeats over and over.  Notice all the skipped frames,
even though the idle CPU time actually increased to about 60% (a bad
thing since that CPU should have been used to get a better frame
rate).  Also there's now a "metronom: video jump" after every two
"ffmpeg: got a picture" successful frame draws.  It's like xine
is getting stuck somewhere doing nothing useful.  As a result, the
resultant video is somewhat jerky rather than very smooth as it
was previously.  Perhaps this is the underlying cause of several
user reports of jerky video with 1_beta4 and recent CVS versions
of xine.

Unfortunately I don't know enough about the internals of xine to
proceed much further, but hopefully this is enough info for one of
the experts to figure out what might be wrong.

						-Bill