#35 randomly spaced white blocks against dark backgrounds

closed-invalid
nobody
None
5
2004-01-14
2003-12-28
Anonymous
No

using mplayer 0.99pre3 and libdv0.99

avi files encoded with libdv occasionally are missing
blocks of uniform black background (show up as small
white blocks in random patterns on dark background)
when displayed with mplayer in linux , studio-8 under
win-doze

The libdv open source codec is the only one I've found
that displays this problem, perhaps as a result of the
very high (fixed) bitrate relative to other codecs?

Discussion

  • Logged In: NO

    encoding to mpeg4 from the original doesn't show any of the
    random blocks, but then converting that mpeg4 to libdv
    causes the garbage to be displayed again, so the bits
    causing the "error" are somewhat persistent in that using an
    intermediate encoder didn't get rid of them. Here's the matrix:

    source dest status
    mpeg2ps libdv shows random
    garbage blocks
    mpeg2ps mpeg4 ok
    mpeg2ps mjpeg ok
    mpeg4 from mpeg2ps libdv shows random garbage
    blocks

    It seems intuitive that there is a bit pattern in the input
    stream that the encoder doesn't know how to deal with, but
    that other codecs are "handling".

     
  • Dan Dennedy
    Dan Dennedy
    2004-01-02

    Logged In: YES
    user_id=78682

    please attach a single stil frame of an image in ppm or png
    format that when encoded through libdv will demonstrate the
    problem.

     
  • Logged In: NO

    An additional piece of information that may prove useful is
    that when I use a video filter and increase to brightness of
    the source stream by 10% before encoding, the missing pieces
    of the frame reappear.

    This might lead me to conclude that the "bug" is in the
    chroma/luma clamping that I read about in the docs. Could
    it be that the source stream contains values outside of what
    the codec expects when dealing with very dark surfaces?

    I would send the requested png frame but I don't see any
    option to do so without creating a login: something that I
    prefer not to do.

    I am usually emailed at tempest766 in the yahoo.com domain
    if you have additional questions or comments.

     
  • Dan Dennedy
    Dan Dennedy
    2004-01-06

    Logged In: YES
    user_id=78682

    I received a small segment of mpeg2 from the bug reporter
    and reproduced the problem in mencoder. I have a workaround;
    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 o 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 ;-)

     
  • Dan Dennedy
    Dan Dennedy
    2004-01-14

    • status: open --> closed-invalid
     
  • Dan Dennedy
    Dan Dennedy
    2004-01-14

    Logged In: YES
    user_id=78682

    I am setting the resolution to Invalid because it is not a
    libdv bug, it is a bug n mplayer's initialisation of libdv.
    The bug report was forwarded to mplayer lead developer
    Arp'i, but he has not responded to confirm that he has
    applied the fix.