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

[Stefan L. <st...@lu...>]

On Montag, 4. April 2005 02:44, Jonathan Woithe wrote:
> Hi all
> 
> 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.

> 
> A very brief glance at the libdv (and the included encodedv) source didn't
> turn up any obvious way to specify whether the input was interlaced or not.
> I don't know if this is an issue, but it's not at all obvious to me how
> libdv can know whether the frames being presented to it are interlaced 
> or not.
> 
> 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?  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
> correct.
> 
> Best regards
>   jonathan
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdv-dev
> 
> 

-- 
Stefan Lucke