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

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

> On Wed, Apr 06, 2005 at 01:40:47PM +0930, Jonathan Woithe wrote:
> > 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.
> 
>   In general, I agree with the way you did your experiments but:
> 
>     1. You shouldn't be doing deinterlancing. There are very few
>        tools for that to handle PAL chroma issues correctly.

Um, the only deinterlacing I did was after the (interlaced) DV frame had
been extracted to a PNG file.  This (as mentioned on the web page) used
ffmeg's decoder via mplayer.  The resulting extracted PNG frame was still
interlaced, so any PAL chroma issues should have been taken care of by the
DV decoder used.  If anything in those frames is caused by chroma issues
then it would indicate a problem in the DV decoder.  In practice the
evidence suggests that the artifacts illustrated are not the result of
chroma mis-handling on decode - see my next point below.  In any case, the
deinterlacing I did was only done once the encoded frame had been extracted
verbatim to a PNG file by mplayer - only then did I load the frame into gimp
for deinterlacing, and this was really only to make the artifacts clearer to
the human eye when displayed on computer monitors.

>     2. The only format that doesn't screw up PAL chroma right away
>        is YUV4MPEG. So you should be using it instead of PNG to
>        store the output of the DV decoders. 

I don't think the chroma is getting adversely screwed by what I'm doing. It
is true that the mjpegtools (which use YUV4MPEG) generally handle the PAL
chroma correctly.  Therefore I am reasonably confident that when my encoded
DV goes to MPEG2 (for use on a DVD player) via mpeg2enc that the chroma will
be handled correctly.  With this supposed correct handling of chroma, the
DVD player shows exactly the field shadow artifacts which are illustrated in
the PNG files I mentioned.

It is possible I'm missing something here though.

The other thing to note is that these artifacts are not present in the raw
footage when that goes to MPEG2 via mpeg2enc having not passed through
libdv's encoder - an observation which is consistent with images I extract
from the raw DV files using the same processes.  This would tend to clear
the analysis side of my method of suspicion I would have thought.

>     3. You might find it usefull to try commercial DV codecs by the
>        virtue of MPlayer .dll handling.

Are there any around which are freely available?  Hmm, Canopus appear to have
a freely downloadable playback only DV codec; I'll see if I can get any
joy out of that.

Regards
  jonathan
-- 
* Jonathan Woithe    jw...@ph...                        *
*                    http://www.physics.adelaide.edu.au/~jwoithe            *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so"                              **
*  "...you wouldn't recognize a subtle plan if it painted itself purple and *
*   danced naked on a harpsichord singing 'subtle plans are here again'"    *