[MPlayer-dev-eng] Fwd: Re: libdv bug report #866569

[Arpi]

interesting!
--------- Forwarded message ---------
From: Dan Dennedy <dan at dennedy.org>
To: Rob Prowel <tempest766 at yahoo.com>, Arpi <arpi at thot.banki.hu>
Subject: Re: libdv bug report #866569

Arpi,
As a libdv project member, the following is the result of researching a
libdv bug report as experienced in mencoder. I know that a diff is
preferred, but it is just a single character change ;-). 

However, given the explanation below about "NTSC setup", you might also
grep for dv_decoder_new and replace the first parameter "TRUE" with a
"FALSE" to prevent the libdv decoder from adding "NTSC setup" on decode.
This issue does not affect PAL at all--the flag is ignored for PAL.

---

http://sourceforge.net/tracker/index.php?func=detail&aid=8665
69&group_id=4393&atid=104393

I received a small segment of mpeg2 from the bug reporter and reproduced
the problem in mencoder. I have a fix for mencoder; edit
MPlayer/libmpcodecs/ve_libdv.c. Find the line that reads:

vf->priv->enc=dv_encoder_new(1,1,1); // FIXME, parse some options!

Replace the first 1 with a 0:

vf->priv->enc=dv_encoder_new(0,1,1); // FIXME, parse some options!

Save.
A simple make would not rebuild properly, so I had to:
cd libmpcodecs
make
cd ..
rm -f mencoder
make

An explanation... the first encoder flag really should almost never be
used. It is used to "undo" the effect of the corresponding flag on the
livdv *decoder*. The flag is for adding 16 luma to simulate what is
called NTSC "setup." This is an analog video term that says add 7.5 IRE
to the luma component--basically required in all NTSC ITU-R 601 decoding
equipment except in Japan where they do not add the setup. If you are
confused, then welcome to the club ;-)

p.s.
Technically, when working with ITU 601 NTSC material in the digital
domain, one is never really supposed to address the "setup" issue, but
some users complained about material looking darker than what appears on
the camcorder viewfinder or TV. Research revealed the setup issue, but
further research reveals proper handling of gamma is another factor.


On Mon, 2004-01-05 at 23:54, Rob Prowel wrote:
> --- Dan Dennedy <dan at dennedy.org> wrote:
> > Can you please send a still frame image from the
> > material that is giving
> > you a problem? Thank you,
> > Dan Dennedy
> 
> 
> Sure thing.  Here's a frame with the dropped blocks. 
> I'm sending as a bzip2 file so it doesn't take so long
> to upload.  If you cannot read bz2 then let me know
> and I'll send it in gzip or uncompressed.
> 
> I have noted that upping the brightness of the input
> stream before encoding with libdv (from within
> mencoder/mplayer) makes the problem go away.  makes me
> wonder if the absolute black nature of the original
> blocks was below the range of what the encoder could
> handle.  The original stream, before encoding with
> libdv, is an mpeg2 stream.  The only reason I'm even
> reencoding with libdv is so that I can edit it in
> Studio8.  The dv format is best for editing in Studio
> at high resolution.
>