Re: [libdv-dev] Possible bug encoding interlaced material?

[Jonathan W. <jw...@ph...>]

Hi Stefan

> > Over the past few months I've been trying to track down the source of
> > flickering during horizontal movement in DVDs I've been making.  The
> > details of all the tests I've done and the results are available for
> > viewing at
> > 
> >   http://www.atrad.com.au/~jwoithe/mpeg/
> > 
> > Initially I thought the problem was with mpeg2enc (from mjpegtools). 
> > However, of particular interest are the last round of tests at
> > 
> >   http://www.atrad.com.au/~jwoithe/mpeg/pantest/
> > 
> > These tests seem to suggest that the root cause of the problem actually lies
> > in libdv's encoder.  It appears that when presented interlaced input, libdv
> > doesn't do the right thing, and perhaps even assumes the input is
> > non-interlaced: each field of the encoded frame contains blocky shadows of
> > the contents of the frame's other field.
> 
> To my opinion there are to issues:
> 1. block artefacts in luma space. If noticed them too, even after first
>    recoding of the same frame with libdv.
> 2. shadows of the other field. This may be related to color handling of
>    other decoders too. As you encode with fps=25 I think you are
>    operating in PAL mode. You converted dv to png with mplayer who
>    uses ffmpeg to my knowledge as default decoder.
>    DV-PAL has different needs when 4:2:0 is decoded as color subsampling
>    is field based and not frame based.

Yes, I am in PAL land (Australia to be precise).  I can also confirm that
the default decoder in mplayer is ffmpeg.

I did some further tests overnight which might be interesting.  These
involved using ffmpeg's encoder to see what it did.  The updated results
are at the bottom of

  http://www.atrad.com.au/~jwoithe/mpeg/pantest/

Essentially I tested ffmpeg's encoder both with a CGI frame and a "real
world" frame.  The upshot was that with the real world frame ffmpeg's encoder
appears to do a good job, while with the CGI input it's better than libdv but
there are still issues.  Note though that these issues might be associated
with the limits of DV's quality - I don't know and can't test this.

Getting back to your comment about there being possibly two issues, I'm not
sure I understand what you're suggesting.  In (1) are you saying that libdv
is having trouble keeping luma information block-free and that this has been
noticed at other times?  My understanding of (2) is that perhaps libdv's PAL
encoder (and maybe its decoder as well) is not as well tested as the NTSC
side of things and that it might still have gremlins lurking in it, and that
these problems might affect ffmpeg's decoder as well?

Regards
  jonathan