#199 melt shows white image, VDPAU surface underrun

head
closed
nobody
5
2014-08-18
2013-08-28
qubodup
No

It appears that most files except ones I convert using ffmpeg on my system (usually to webm) only show up as white and create the following output in melt:

VDPAU surface underrun
[h264 @ 0x7f1f3c0044a0] get_buffer() failed
[h264 @ 0x7f1f3c0044a0] thread_get_buffer() failed
[h264 @ 0x7f1f3c0044a0] decode_slice_header error
[h264 @ 0x7f1f3c0044a0] no frame!

webm files downloaded from youtube using youtube-dl have the same issue.

An example file is https://app.box.com/s/dpiuc8kifodgp7scnfi7

This happens in melt 0.9.0 as well as git20120912.

I run arch linux 64bit with xf86-video-ati 1:7.2.0-1.

Any idea what is happening or how I can provide useful information?

Note: I had reported this as a Kdenlive issue on http://forum.kde.org/viewtopic.php?f=265&t=117076&p=291018

Discussion

1 2 > >> (Page 1 of 2)
  • qubodup
    qubodup
    2013-08-28

    PS: x264 "version" is 20130702-2

     
  • Dan Dennedy
    Dan Dennedy
    2013-08-28

    I will see if I can I reproduce it, but I doubt it as I did last use VDPAU successfully as recent as May 2 when testing a patch submission related to VDPAU.

    I strongly discourage enabling vdpau in Linux package because it only seems to work good for simple media players when not enabled by default. So, I filed a bug against the package:
    https://bugs.archlinux.org/task/36710

    Also, I wonder why it is trying to use VDPAU when you have an ATI card! VDPAU is only for NVIDI!?

     
  • Dan Dennedy
    Dan Dennedy
    2013-08-28

    • Group: feature_request --> head
     
  • Dan Dennedy
    Dan Dennedy
    2013-08-28

    I can confirm that it correctly fails to detect a vdpau implementation inside a virtual machine:
    [producer avformat] /home/ddennedy/Videos/test.mp4
    vdpau_init: failed to dlopen libvdpau.so
    (/usr/local/lib/libvdpau.so: cannot open shared object file: No such file or directory)

     
  • Dan Dennedy
    Dan Dennedy
    2013-08-29

    On my machine with NVIDIA, I just tested that it works for me, but please be aware that I am building FFmpeg and MLT from source, and not testing the Arch package. I am not sure what I can do here except to leave the ticket open for a while to see if other users report similar problems and get a different perspective on the problem.
    ddennedy@ddennedy-MS-7593:~/src/mlt$ melt -debug ~/Videos/00018.MTS 2>&1 | grep vdpau
    vdpau_init
    vdpau_decoder_init
    vdpau_get_buffer
    [h264_vdpau @ 0x1109600] no picture
    vdpau_get_buffer
    vdpau_get_buffer
    vdpau_release_buffer (3)
    vdpau_release_buffer (4)
    vdpau_release_buffer (5)
    vdpau_producer_close
    vdpau_fini (1)
    vdpau_init
    vdpau_decoder_init
    vdpau_get_buffer
    [h264_vdpau @ 0x7ff08c025bc0] no picture
    vdpau_get_buffer
    vdpau_get_buffer
    vdpau_get_buffer
    vdpau_release_buffer (5)
    vdpau_release_buffer (4)
    vdpau_get_buffer
    vdpau_get_buffer
    vdpau_get_buffer
    vdpau_release_buffer (8)
    vdpau_release_buffer (7)
    vdpau_get_buffer
    vdpau_get_buffer
    vdpau_get_buffer
    vdpau_release_buffer (8)
    vdpau_release_buffer (4)
    vdpau_get_buffer
    vdpau_release_buffer (3)
    vdpau_get_buffer
    vdpau_get_buffer
    vdpau_release_buffer (4)
    vdpau_release_buffer (8)
    vdpau_get_buffer
    vdpau_release_buffer (6)
    vdpau_get_buffer
    vdpau_get_buffer
    vdpau_release_buffer (8)
    vdpau_release_buffer (4)
    vdpau_get_buffer
    vdpau_release_buffer (5)
    vdpau_get_buffer
    vdpau_get_buffer
    vdpau_release_buffer (4)
    vdpau_release_buffer (8)
    vdpau_get_buffer
    vdpau_release_buffer (7)
    vdpau_get_buffer
    vdpau_release_buffer (3)
    vdpau_get_buffer
    vdpau_release_buffer (4)
    vdpau_release_buffer (8)
    vdpau_get_buffer
    vdpau_get_buffer
    vdpau_get_buffer
    vdpau_release_buffer (4)
    vdpau_release_buffer (3)
    vdpau_get_buffer
    vdpau_release_buffer (6)
    vdpau_get_buffer
    vdpau_get_buffer
    vdpau_release_buffer (3)
    vdpau_release_buffer (4)
    vdpau_get_buffer
    vdpau_release_buffer (5)
    vdpau_get_buffer
    vdpau_release_buffer (7)
    vdpau_get_buffer
    vdpau_release_buffer (3)
    vdpau_release_buffer (4)
    vdpau_get_buffer
    vdpau_get_buffer
    vdpau_get_buffer
    vdpau_release_buffer (3)
    vdpau_release_buffer (7)
    vdpau_get_buffer
    vdpau_release_buffer (8)
    vdpau_get_buffer
    vdpau_get_buffer
    vdpau_release_buffer (7)
    vdpau_release_buffer (3)
    vdpau_get_buffer
    vdpau_release_buffer (6)
    vdpau_get_buffer
    vdpau_get_buffer
    vdpau_release_buffer (3)
    vdpau_release_buffer (7)
    vdpau_get_buffer
    vdpau_release_buffer (5)
    vdpau_get_buffer
    vdpau_get_buffer
    vdpau_release_buffer (7)
    vdpau_release_buffer (3)
    vdpau_get_buffer
    vdpau_release_buffer (4)
    vdpau_get_buffer
    vdpau_release_buffer (5)
    vdpau_release_buffer (7)
    vdpau_release_buffer (6)
    vdpau_release_buffer (8)
    vdpau_release_buffer (3)
    vdpau_producer_close
    vdpau_fini (1)

     
  • Dan Dennedy
    Dan Dennedy
    2013-08-29

    As a workaround, you can execute kdenlive with the environment variable MLT_NO_VDPAU=1 to prevent MLT from trying to use VDPAU. From a command line:
    MLT_NO_VDPAU=1 kdenlive

     
  • qubodup
    qubodup
    2013-08-29

    Thanks for pointing this out. mlt in arch linux is by default compiled with --avformat-vdpau. I re-compiled with the line removed from ./configure and now melt plays back videos correctly!

    mesa and mplayer depend on libvdpau in arch linux it appears.

    Is it a bug that melt can't make the determination that vdpau should not be used on this system at runtime? Or is it by design, that it's being used, if it's enabled during compilation?

     
  • qubodup
    qubodup
    2013-08-29

    Also thanks for the workaround.I'll share it in the Kdenlive forum.

     
  • Dan Dennedy
    Dan Dennedy
    2013-09-07

    • status: open --> pending
     
  • Dan Dennedy
    Dan Dennedy
    2013-09-07

    Changing to pending, which will get closed after some months as I have not been unable to reproduce and reviewed the source code.

     
1 2 > >> (Page 1 of 2)