[TheSwissKnife]

Thanks for the help: PM sent with a link to some file samples.

Some H.264 streams - SD or HD - play fine, and those that don't have problems whatever the file format. So it's clearly an issue with the video stream itself, or how ffmpeg/VDPAU is handling it, anyway. All I can say is that I've got it on streams from different sources, so it's not a unique encoding even if it's perhaps non-standard or similarly screwed up.

I stumbled across this recent patch for ffmpeg which I'm aiming to try, but there's no real information as to what problem it fixes. Clutching at straws, though, I know.

Thanks again...

If I recall I already tried that ffmpeg patch before with no luck. By all means give it a go to confirm but don't clutch the straws to tight.

[doestergaard]

I'm not running on the eden-pre version, but have you upgrated to the latest driver from NVIDIA? If yes don't! I had the same problem but got it fixed with downgrading to a lower version. I will go now and find out which version of the driver i have and I'll get back to you.

If i haven't read too fast, I assume you are running on a NVIDIA system?

[Prof Yaffle]

Thanks, doestergaard - yes, Nvidia, ION chipset. Currently on 270.41.06, but I've tried other recent variants (I think... I've tried so many configurations even I'm confused!).

The current release seems to be 280.13, I haven't tried those and am not inclined to if you've had problems, not without a reason.

I must confess that I'm getting close to either re-encoding the files or just buying a more powerful box that doesn't need VDPAU :-)

[FernetMenta]

You have gone this far, you can't give up.

You might have posted it somewhere in this thread but I couldn't find it. Is your OS 32 or 64 bit?

[doestergaard]

Thanks, doestergaard - yes, Nvidia, ION chipset. Currently on 270.41.06, but I've tried other recent variants (I think... I've tried so many configurations even I'm confused!).

The current release seems to be 280.13, I haven't tried those and am not inclined to if you've had problems, not without a reason.

I must confess that I'm getting close to either re-encoding the files or just buying a more powerful box that doesn't need VDPAU :-)

Hi again! sorry for not getting back to you, have been busy. I'm running this version http://www.nvidia.com/object/linux-displ...river.html and it works without any problems! I mean this driver has support for ION but check you're chip is listed. Also make sure you're not running on 64 bit system. In my experience, it doesn't work well.

Hope this helps.

[Prof Yaffle]

Thanks again, doestergaard - I'll maybe try a different driver version at some point. It just means a recompile of a couple of things, so I'll probably take a deep breath and combine it with a kernel update.

@FernetMenta - don't worry, I'm not *quite* surrendering yet... well, maybe not :-) ... 32-bit, since you asked:

Code:

xbmc@XBMCLive:~$ uname -a
Linux XBMCLive 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:21 UTC 2011 i686 GNU/Linux
xbmc@XBMCLive:~$ uname -m
i686
xbmc@XBMCLive:~$

[EricV]

Hi again! sorry for not getting back to you, have been busy. I'm running this version http://www.nvidia.com/object/linux-displ...river.html and it works without any problems! I mean this driver has support for ION but check you're chip is listed. Also make sure you're not running on 64 bit system. In my experience, it doesn't work well.

Hope this helps.

It does work well on 64 bits... Better than on 32 bit performance wise...

[Prof Yaffle]

Apologies to anyone who thought I'd gone away or given up... but I'm not done yet :-)

EricV - thanks, I did get your email about external ffmpeg, but family issues have kept me away from this for a while. I may yet come back to that.

However... cue trumpets... I think I've made a breakthrough. The files that cause the problem all appear to have a non-standard Y resolution, which seems to be what's choking VDPAU.

For example, if I play a file in VLC or XBMC, it reports that a corrupt file is 1280x720. However, dropping it into Osmo4 shows me that the real video stream is 1280x724. Similarly, the SD files I had grief with are nominally 640x360 - but the video stream in reality is 640x372. Anyone who's quick with their fingers will realise that the real resolutions are not multiples of 8 on the Y axis.

The H.264 files that work correctly are all 8x multiples, plus the container "metadata" as reported by most media players matches the underlying stream. That's why re-encoding the files works - it forces these to be correct while re-sampling the video stream.

So, either:

1. VDPAU is simply choking on something that isn't an 8x multiple (even though non-VDPAU playback works without corruption), or

2. VDPAU is having a bad hair day when the container says one thing but the reality is something else.

Time to ask for help again... can anyone verify this for me? Can you generate a file that has a mismatch in Y resolutions and/or test something that has a non-multiple-of-8 Y axis? I'm trying to find a way of forcing things, but maybe someone has a bright idea out there...

*** EDIT ***

Okay, done some homework - I've thrown every "edit-this-file" application I can find on Windows and Linux at the file, and can't over-ride anything that makes VLC (at least) see it as 1280x724. The file resolutely stays at 1280x720.

However, I did turn up a post about H.264 Video Usability Information ("VUI" - aspect ratio, colourspace and similar) and how this may actually be stored as an extra 4 lines in some way. Could be a complete red herring (it wouldn't explain the 12 line on the SD files), but in case someone understands this I thought it worth mentioning.

[FernetMenta]

Code:

So, either:

1. VDPAU is simply choking on something that isn't an 8x multiple (even though non-VDPAU playback works without corruption), or

2. VDPAU is having a bad hair day when the container says one thing but the reality is something else.

I have tried your sample files with GT220 and ION2 and still can't duplicate this issue.
Ubuntu 10.10 (32 bit)
Cpp : 4.4.5

EDIT:
I have noticed another difference: VAAPI is disabled on my system, enabled on yours. Can you reconfigure and disable VAAPI?

[Prof Yaffle]

Since this seems to be limited to me, I start to wonder if it's a Revo R3600 problem and/or original ION and/or Ubuntu 10.04. Your post got me thinking, so I upgraded libvdpau on my dev image to 0.4-3 (0.3-2 ships with Lucid) to see if that changed anything... nope.

I'd try Openelec if it supported my tuner cards (and if I had a pair of spare USB sticks to hand)... maybe I need to build a fresh Maverick or Natty system and see if that helps, although I do like the convenience of XBMC Live.

Re: your post, FernetMenta... CPP? C pre-processor?

Anyway... System -> Settings -> Video -> Playback

1. Dev box, running self-build git:20110719-2d77939 - no option for VAAPI, so I don't know where that went!

2. Production box, running Dushmaniac's 30-08 build (no package info since he moved the PPA to PulseEight) - VAAPI is disabled, and I think I've tried every combination of these options.

I'm convinced that it's this video height issue, but I don't know why - whether it's a library, or ffmpeg, or something else, whether it's expecting multiples of 16 or 8 and choking, whether it's because it's an odd aspect ratio... pass.

Starting to annoy now. I'd simply re-encode the files, except live streaming still wouldn't work if the broadcasters are transmitting odd files (which they seem to be).

[FernetMenta]

Cpp -> C++

Let me check, maybe I can add debug code to vdpau slice decoding and verify your theory.

[Prof Yaffle]

Thanks, as always.

As another reference, I remembered that I had an old 32-bit/10.10 image lying around, so booted into that - 10.1 Dharma worked fine, installed the latest OdK build and the corruption is back (after hacking around an update to libva to get it to work). So it's not a distro issue per se, and the behaviour definitely arrives with the newer XBMC code. I'm just installing 500Mb of patches onto that system t bring it up to date just to make sure...

Still points a finger at ffmpeg to me, so I'll go back to seeing if I can compile that externally when I have a spare few hours.

[FernetMenta]

(after hacking around an update to libva to get it to work)

I am confused. What are you doing with libva (VAAPI)? This is from your log post #8 of this thread:

Code:

DEBUG: CDVDFactoryCodec: compiled in hardware support: CrystalHD:yes OpenMax:no VDPAU:yes VAAPI:yes

Maybe ffmpeg mixes something up when it gets compiled with support for vdpau and vaapi since vdpau can also act as a backend driver for vaapi.

[Prof Yaffle]

Hey, I'm just as confused as you, I assure you!

If the debug log shows both enabled, that was simply what I was trying at the time. I've tried both, VAAPI only, VDPAU only and neither - the corruption only appears when VDPAU is switched on. Normally, I'd only have VDPAU enabled, VAAPI is switched off (unless it's on by default for some reason).

Re: libva, when I tried to start Dushmaniac's xbmc it complained about libva versions - I suspect his PPA carries 1.0.1.3 (or something similar) but it wouldn't install because it couldn't overwrite vainfo, which is a package in its own right. Uninstall that, manually install libva1, and xbmc would then start. But I'm not using VAAPI (at least, not intentionally) - it's simply a dependency that XBMC is looking for.

I think the default XBMC compilation includes both VDPAU and VAAPI, though, doesn't it? Dushmaniac's default build appears to. Interesting question, though...

[Prof Yaffle]

Hmmmm.... see this link.

And I quote:

"What has happened is they now encode the 1280x720 stream as 1280×724 with 4 lines of bottom crop which should bring it back to 1280×720. The problem is, many players don’t understand the bottom crop directive. VLC and Adobe Media Player/Flash play it correctly. The Quicktime included in 10.6.3 plays it with a green line 4 pixels tall at the bottom. The Quicktime pre-10.6.3 and the version currently in the Apple TV refuse to play the video altogether. There is no real solution other than to hope everyone gets their players to support the bottom crop tag. That or completely re-encode every video. Note: This is not a problem with the flv-mp4 conversion."

Sound familiar, anyone?

EDIT:

I tested the sample files the poster here reported and, lo and behold, I can see that they're 1280x724 instead of 1280x720, and my old friend the wavy green corruption is there.

Soooooo...

What does XBMC actually do when you enable VDPAU? Does it pass the video stream to a different chunk of playback code ("accelerated video" versus "non-accelerated video") which then calls something in ffmpeg for decoding? It would seem that the non-accelerated code understands that it needs to crop (process, discard, whatever) and can play the file, but the accelerated code doesn't.

I would suspect libvdpau, except this played the files fine in earlier releases, so it's back to the ffmpeg update and how the video stream goes from XBMC to ffmpeg to libvdpau.

It may be a completely spurious fact, but ffmpeg changed from "-cropbottom n -cropleft n1..." parameters to "-vf crop=W:H:x:y" sometime last year. Just makes me curious...