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

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

Hi Roman

> On Mon, Apr 04, 2005 at 10:14:44AM +0930, Jonathan Woithe wrote:
> > 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 make things a little bit clearer could you, please, run your
>   experiments using ffmpeg instead of libdv. Both for encoding and
>   decoding.

I actually tried this but things went pear-shaped fairly rapidly.  This was
a CVS snapshot of ffmpeg from 3 March 2005.  Initially I couldn't work out
how to convince ffmeg to accept a series of stills as input; eventually I
resorted to mencoder to write a MJPEG movie (just for the purposes of these
tests, since it's lossy and therefore undesireable at this stage of the
pipeline) which ffmpeg then accepted.  When I then used ffmpeg to output a
raw DV file encoded using libavcodec's DV codec, the resulting frames were
garbled almost beyond recognition (the mjpeg movie was fine when played in
mplayer).  At this point I gave up since the whole ffmpeg route seemed too
fragile and I didn't have time to pursue it further - I don't know for
example if the trouble was the mjpeg file produced by mencoder or the ffmpeg
codec itself).

I should note at this point that libdv's decoding appears to be fine.
Although not explicitly tested by me, viewing interleaved frames from raw
(from camera) DV data do does not seem to show the artifacts I see when the
libdv encoder has been used.  I will test this though, for completeness.

> > Anyway, what do others think?  Is this an issue?  Is there a way to get
> > around it so interlaced material is encoded correctly to DV by libdv?
>   
>   Oh, yeah! Use ffmpeg :-)

Unfortunately I need DV codec functionality in other programs such as
cinelerra (among others) and it is not entirely trivial to do this at this
point in time.

> > While having encodedv work correctly would be good, a general libdv
> > solution is the most important consideration from my point of view since
> > it would mean that the output from programs which use libdv (such as
> > cinelerra) would be
> 
>   Last I've heard cinelerra had a way of using ffmpeg's DV codec instead
>   of libdv. 

The unofficial CVS folks are working on it, but my reading of their mailing
list suggests it's not really production ready at this point, and besides,
at the present moment I need something which "just works".  A fix to libdv
would probably be easier than a wholescale move to ffmpeg's codec.

Regards
  jonathan