[LINUX] HD Video Corruption with pre-11.0 PVR (ffmpeg?) and VDPAU

Prof Yaffle · 2011-06-24 19:49

@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.

Prof Yaffle · 2011-06-26 21:46

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).

**FernetMenta** · 2011-06-27 09:45

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.

Prof Yaffle · 2011-06-27 21:10

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...

Prof Yaffle · 2011-06-27 23:30

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!

**FernetMenta** · 2011-06-28 08:44

Quote: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...

This is quite a good idea and I don't think it would be a slow process. I guess you can narrow down the number of commits to look at to 5 with less than 10 build cycles. I would start with Dharma: git reset --hard e9e909922ed87c4f0bc9 sets the version to March 4th. If this version is ok go to the middle of this date and today, always divide by 2.

Prof Yaffle · 2011-06-30 11:54

I suspect I'll need to rebuild this image before I start this process, but that's doable. i'll try a total wipe of XBMC first and see if that helps.

Maybe I'm just having a bad day, though, but how does the git date coding work? I've wandered back through the commits and sort of see a pattern sometimes. Ideally, though, I'd be able to just generate that hex code (or some other reference) and take it from there.

I know the fault appeared in early April, so that will save some binary splitting of dates... I guess I'll nail it to a specific date within a few builds...

**FernetMenta** · 2011-06-30 23:05

Prof Yaffle Wrote:Maybe I'm just having a bad day, though, but how does the git date coding work? I've wandered back through the commits and sort of see a pattern sometimes. Ideally, though, I'd be able to just generate that hex code (or some other reference) and take it from there.

I am away from my system and can't try but I think you can log out git hash and commit date with:
git log --pretty=format:%H %cd

Or use git log --grep to find specific ones.

Prof Yaffle · 2011-07-03 13:30

Thanks - then let the game begin. I see that git has a handy bisect option that should nail me down to the right few days in four binary splits or so, so let's see. I know that the shipping version of XBMC-Live is good, and i can mark the current code as bad, so that's only 16-18 weeks or so between.

I need to play a bit more with the commit numbering scheme (thanks for the pointers), I'm getting errors from git bisect when I try something from git log or the github history, so I'm evidently doing something wrong.

Once I get things working I'll open a post here as a diary/reference for anyone who may be interested.

TheSwissKnife · 2011-07-03 13:59

I would suggest looking (and asking) about each commit when the ffmpeg release that is incorporated changed. It would seem to me to be very clearly related to that.

Prof Yaffle Member+ Posts: 489 Joined: Mar 2011 Reputation: 3 Location: UK - in the middlish (mostly).	2011-06-24 19:49 Post: #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.
	find quote

Prof Yaffle Member+ Posts: 489 Joined: Mar 2011 Reputation: 3 Location: UK - in the middlish (mostly).	2011-06-26 21:46 Post: #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).
	find quote

TheSwissKnife Fan Posts: 325 Joined: Sep 2010 Reputation: 17	2011-07-03 13:59 Post: #50 I would suggest looking (and asking) about each commit when the ffmpeg release that is incorporated changed. It would seem to me to be very clearly related to that.
	find quote