• 1
  • 2
  • 3(current)
  • 4
  • 5
  • 11
[LINUX] HD Video Corruption with pre-11.0 PVR (ffmpeg?) and VDPAU
#31
Thanks, guys - I suppose replication is the first step towards resolution!

Let me know how I can help, happy to do what I can with my limited compilation skills - test things, provide more details, apply patches, etc. I wish I could help more with the code, but my last serious application was 20 years ago and in FORTRAN, so I'm not what you'd call "up to date"!
Reply
#32
It plays ok with vdpau switched off on my system.
Reply
#33
Can someone who can duplicate this problem upgrade to vdpau 0.4.1, reconfigure, and build xbmc.
http://cgit.freedesktop.org/~aplattner/libvdpau/
Reply
#34
I don't think there are any real code changes are there?

I don't have access to a package for that so it would get a bit messy.
Reply
#35
Happy to have a look, but you'll need to spoonfeed me some instructions - I just looked at the VDPAU zip file and it's a little light on documentation, having blank README and INSTALL files, for example. Maybe it's better if someone knowledgeable has a go, but I will if no-one else volunteers...
Reply
#36
Just extract the tar and then:

./configure
make
sudo make install
Reply
#37
Thanks, but not quite - there's no configure script in the libvdpau archive - but there was an autogen.sh script which calls autoreconf to generate it. So that's done, libvdpau is compiled and installed, and I'm just refreshing my git XBMC code... compile soon, I'll let you know in due course.

All I can do is check the timestamps on the libvdpau files to see that they're current (they are, it's all timestamped a few minutes ago), but is there any way of confirming that it is 0.4.1 when XBMC starts?
Reply
#38
Quote:All I can do is check the timestamps on the libvdpau files to see that they're current (they are, it's all timestamped a few minutes ago), but is there any way of confirming that it is 0.4.1 when XBMC starts?

I don't think you can see this when XBMC starts. Think of vdpau as an API or specification. It's just the header files and a wrapper library which is not used by XBMC (only for static linking).
XBMC, ffmpeg, and the graphics driver depend on this specification. There has been no big change in the API and there might be only a little chance that this causes the issue. But at least we would be able to exclude another possible problem.
Reply
#39
I play the file fine with older xbmc and its older ffmpeg - same vdpau lib and nvidia driver.
Reply
#40
No luck so far - I can't even get to test it.

My normal compile script failed, so I built the git code the old-fashioned way - but something got eaten so start xbmc-live no longer works. XBMC seems to start but then cycles through display modes indefinitely.

So I reverted to the version of FernetMenta's PVR code I tested the other day, and recompiled/installed that. X now won't start at all, which I really can't blame on the build unless "make install" changes the X config in some way.

Anyway, I'm now fully-patching the machine to make sure I'm not getting some other dependency/version problems and then I'll try again. It's not impossible I'll have to do a rebuild to ensure I've got a clean system to play with, so this might take me some time...
Reply
#41
@TheSwissKnife - yes, these files worked perfectly prior to early April - that's when I first noticed the problem in Dushmaniac's PVR build, so he inherited something from the main trunk that started the issue.
Reply
#42
Okay, my xbmc-live config is ruined, but I managed to bludgeon X11 and xbmc into life, using the FernetMenta 20110616-79c3394 code, compiled after compilation and installation of the the new VDPAU libraries.

No change, I'm afraid - a corrupt as a corrupt thing. So it's not that (on its own, at least).
Reply
#43
I am sorry that you are having this trouble with your system. If you are still in the mood to try things, I have another one.

VDPAU.cpp
Code:
if(pFrame)
  { // we have a new frame from decoder

    vdpau_render_state * render = (vdpau_render_state*)pFrame->data[2];
    if(!render) // old style ffmpeg gave data on plane 0
      render = (vdpau_render_state*)pFrame->data[0];

ffmpeg header states that buffers for vdpau are on plane 0 (data[0]). I have changed the code to:

Code:
if(pFrame)
  { // we have a new frame from decoder

    vdpau_render_state * render = (vdpau_render_state*)pFrame->data[0];
    if(!render) // old style ffmpeg gave data on plane 0
      render = (vdpau_render_state*)pFrame->data[0];

Still works. Maybe the corrupted data is on plane 2.
Reply
#44
Hey, this system is ruined already - what am I going to do, break it? :-)

I changed that piece of code (well, that one character, anyway, so unless I missed something...), recompiled/installed and it made no difference. Close another line of investigation.

Thanks for trying on this, it is appreciated.

I did wonder about trying to find the exact code version when the problem appeared, and then we'd at least know what commits were made to what modules. Might be a slow process, though...
Reply
#45
As an aside - as far as I can tell (we really need some better "I'm using these libraries/I was compiled with these options" flag in the system information...), I successfully compiled using --enable-external-ffmpeg after installing a recent (last weekish) ffmpeg build. Corruption is still evident, though, so it's either something to do with how XBMC handles ffmeg and/or VDPAU, or it's an inherited problem, from libvdpau or ffmpeg or similar.

In other words... utterly inconclusive!
Reply
  • 1
  • 2
  • 3(current)
  • 4
  • 5
  • 11

Logout Mark Read Team Forum Stats Members Help
[LINUX] HD Video Corruption with pre-11.0 PVR (ffmpeg?) and VDPAU0