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

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

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

Yes, I understand that (I think).  What puzzles me a bit though is that in
the toolchain I used for this, mplayer (using ffmpeg's DV codec) was
responsible for writing the extracted (interlaced) frame in PNG format from
the raw DV stream:

  mplayer -vo png -z 9 foo.dv

Therefore, any necessary colourspace conversions were handled by
mplayer/ffmpeg.  Assuming this is true, if there is a chroma problem in
these extracted images it must therefore mean that the colourspace
conversion in mplayer/libavcodec doesn't get it right.  In principle at
least, mplayer should be capable of extracting a (interlaced) frame
(interlaced YUV420), doing YUV420->RGB conversion (giving interlaced RGB)
and writing the resulting frame out to some format.  The accuracy of the
conversion would be limited to mplayer's algorithm and the internal image
formats used by mplayer - the actual output format shouldn't come into it.

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

Ok, so from all this I take it that the conversion is not supplied by libdv
and that therefore it's possible that the conversion in mplayer isn't up to
scratch when considering these artifacts?

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

For completeness I'll try this over the weekend.

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

From DV to MPEG2 I use tools only from mjpegtools.  These do of course use
libdv's decoder.  I haven't as yet had time to work out how to get ffmpeg
into the pipeline - I'll see if time allows such experiments over the
weekend.  Anyway, given a DV stream (in a QT container, but that's not
relevant for this), the process at its simplest form is

  lav2yuv foo.mov | mpeg2enc -f 8 -q 6 -N 0.5 -E -10 -c -s \
    --no-dualprime-mpeg2 -D 10 -o foo.m2v

were foo.mov is a raw DV stream encapsulated in a Quicktime file.

If foo.mov is raw footage captured directly from a camera using dvgrab (ie:
having undergone *no* processing on the computer at all), movement on the
resulting DVD is smooth with no field shadows appearing in the frames. 
Extracting frames to PNG from such a file using mplayer as described
elsewhere similarly shows no field shadow artifacts.  If, however, foo.mov is
the same footage but run through a libdv decode/encode cycle the movement on
the DVD is not smooth and frames (both extracted on the computer and on the
DVD) display the field shadows.

As an aside, based on other tests I've done I would expect that the footage,
after run through the ffmpeg encoder, will look better on the DVD than that
encoded with libdv but that there will still be issues.  I'll try to confirm
this over the weekend.

I haven't yet had a chance to look into how one could use ffmpeg to do the
DV->YUV4MPEG conversion - it's another thing for the weekend.  Based on the
results of my earlier tests though I don't expect this to make a great deal
of difference.  As far as the decoders go, ffmpeg and libdv seem (at first
glance anyway) to give equivalent output.

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

The webpage has a bz2 tarball of a series of still interlaced CGI PNG images
which comprise one of my test cases (the logo*.png files mentioned on the
website).  That is available now - see the link to still_pngs.tar.bz2 on

  http://www.atrad.com.au/~jwoithe/mpeg/
  
Unfortunately I don't have the raw camera DV footage with me today - I'll
bring it with me on Monday and advise when it's available.

Regards
  jonathan