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

[Roman S. <rv...@Su...>]

On Thu, Apr 07, 2005 at 04:18:12PM +0930, Jonathan Woithe wrote:
> > 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.  

  Nope. PNG uses RGB color space, while PAL DV operates in YUV420, thus
  you need a conversion. And the conversion of PAL chroma is a picky
  thing.

> If anything in those frames is caused by chroma issues
> then it would indicate a problem in the DV decoder. 

  Unfortunately, you can't really tell whether you've got artifacts from
  the colorpsace conversion or from the decoder. That's the reason I recommend
  using YUV4MPEG.

> 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.

  I understand your reasons, but as I've explained earlier, the correct
  sequence of steps to get a truly telling result would be:
     
     1. Extract to YUV4MPEG (make sure it's labeled as PAL).
     2. Use the deinterlacer from the mjpeg tools.

> >     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. Believe me.

> 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.

  That is a correct assumption.

> 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.

  Hm. That is interesting. Could you show us the full command line you use
  to go from DV to MPEG2 using ffmpeg and mjpegtools ?

> The other thing to note is that these artifacts are not present in the raw
> footage.

  Interesting. Could you post a sample of that raw footage somewhere for
  me to play with ?

> >     3. You might find it useful 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.

  I think Sony and Mainconcept have "free" ones.

Thanks,
Roman.