Initial native support for DXVA2 in SVN - Time to say goodbye to your firstborns

Initial native support for DXVA2 in SVN - Time to say goodbye to your firstborns - Printable Version

+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Help and Support (/forumdisplay.php?fid=33)
+--- Forum: XBMC General Help and Support (/forumdisplay.php?fid=111)
+---- Forum: Windows support (/forumdisplay.php?fid=59)
+---- Thread: Initial native support for DXVA2 in SVN - Time to say goodbye to your firstborns (/showthread.php?tid=69306)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121

- elupus - 2010-04-19 18:53

CrystalP:
If you can split it into steps that are selfcontained that is absolutely preferable. A tip is to use git if you are familiar with it. Then you can rebase when stuff changes in our tree and develop in steps, without waiting for a patch to get applied to our tree.

On windows msysgit is your tool of choice. Not tested tortoisegit, but that might be in a usable state nowadays.

You don't need to create separate Trac entries for each patch thou, as you are working towards a final goal (semi final anyway).

I suspect the final patch won't be that huge anyway, so if you want to do it in one go that should be okey aswell, but might take more review before being accepted.

- CrystalP - 2010-04-20 00:12

Elupus,

Thanks for the guidelines. I started with the SVN repository (it's the only way mentionned in the HOWTOs) and will look for information on git as I go.

P.

- WisdomWolf - 2010-04-20 06:18

CrystalP Wrote:@WisdomWolf:

I tried a similar setup: ATI 4550 with two screens (primary) and nVidia GT8500 with the TV.
XBMC only detected the two screens on the primary adapter. Screen #3 (the TV) wasn't even listed, so that was a showstopper.

A quick look at the source code of XBMC reveals that it hardcodes a primary and a secondary screen in places, no matter the total amount of physical screens. So three screens or more doesn't work right.

Now for some good news... XBMC and DXVA work fine on a computer with two different brands of graphics cards! I unplugged one of the screens on the ATI card, and voila, XBMC detected the TV on nVidia, let me use it, and DXVA simply worked (with the usual caveats, black/green screens, etc..)!

Great job elupus, I wasn't expecting it to work flawlessly in this uncommon setup!

Well it seems you confirmed my fear with your second test. If you were getting green screens and such on the TV which was connected via Nvidia it looks like that's not the card that DXVA was using. I am fairly certain that those issues are ATI issues. So, does that mean that all the rendering/offloading is still happening on the ATI card and then being passed to the Nvidia card?

- CrystalP - 2010-04-20 08:10

I didn't mean to sound negative - DXVA generally works, with the caveats already noticed in this thread.

I am pretty sure the DXVA processing happens on the correct card because there is a difference in the DXVA capabilities reported in the debug log depending on the screen used for playback. And it matched what I knew of the cards: the nVidia 8500GT has basic VC1 accel and there was VC-1 IDCT in the log with nVidia playback, while the ATI 4550 can do full VC1 and there was VC-1 VLD in the log with playback on a screen attached to the ATI. Hope that was clear...
On top of that, the problematic videos give different artifacts on ATI and nVidia, and that's what I observed as well.

Regarding 3+ screens support, I wrote a patch that gives full functionnality (including DXVA) and added it to an old ticket reporting the issue (ticket #7365). You were right Elupus, it's a pretty small patch, as most of the support was already there for other platforms. I will create a specific forum post too.

Back on topic, I noticed a weird problem with the Gladiator sample. On ATI, there is the green bottom half/slightly smeared around the middle but otherwise normal top half that other people reported, but leaving the clip running til the end triggers this in DXVA.cpp, CProcessor::Render() line 927:

Code:

CHECK(m_process->VideoProcessBlt(target, &blt, samp.get(), valid, NULL));

Stopping the video before it finishes doesn't trip the CHECK().

On nVidia, the image is perfect, but leaving the clip running til the end gives this:

Code:

Unhandled exception at 0x5c8423bd in XBMC.exe: 0xC0000005: Access violation reading location 0xfeeefeee.

and the debugger doesn't have a valid location.

Again, stopping the video before the end doesn't do anything bad.

So something bad happens when the video finishes on its own, and nothing happens when it is stopped before the end. This doesn't happen for every clip/movie. Any ideas for things to check?

- elupus - 2010-04-20 12:17

Sounds like something getting released but then still used.

- CrystalP - 2010-04-22 08:57

I may have found the 'something' with the help of the DXVA Checker tool. The same thing happened for ATI and nVidia.
When leaving the Gladiator sample run to the end, the last lines of the DXVA calls/events log are:

Code:

DXVA2_DecodeDeviceGetBuffer, XBMC, 00:00:44.4752141

DXVA2_DecodeDeviceExecute, XBMC, 00:00:44.4752192

DXVA2_DecodeDeviceEndFrame, XBMC, 00:00:44.4752789

DXVA2_DecodeDeviceExecute, XBMC, 00:00:44.4756958

DXVA2_ProcessBlt, XBMC, 00:00:44.5234321

DXVA2_ProcessBlt, XBMC, 00:00:44.7596188

DXVA2_DecodeDeviceDestroyed, XBMC, 00:00:44.7945544

DXVA2_ProcessBlt, XBMC, 00:00:44.8636853

The last line seems to correspond to the m_process->VideoProcessBlt() that produces the exception in the debugger.
Calling ProcessBlt after destroying the decoder doesn't seem right, or are these resources independent?

For comparison, stopping the sample before the end produces these last lines in the DXVA Checker log:

Code:

DXVA2_DecodeDeviceGetBuffer, XBMC, 00:00:10.8653753

DXVA2_DecodeDeviceExecute, XBMC, 00:00:10.8653800

DXVA2_DecodeDeviceEndFrame, XBMC, 00:00:10.8654393

DXVA2_DecodeDeviceExecute, XBMC, 00:00:10.8656735

DXVA2_DecodeDeviceExecute, XBMC, 00:00:10.8960410

DXVA2_DecodeDeviceBeginFrame, XBMC, 00:00:10.8962155

DXVA2_ProcessBlt, XBMC, 00:00:10.9463290

DXVA2_ProcessBlt, XBMC, 00:00:10.9791766

DXVA2_DecodeDeviceDestroyed, XBMC, 00:00:11.3313175

DXVA2_ProcessDeviceDestroyed, XBMC, 00:00:11.3591498

I also compared XBMC logs with MPC-HC logs for the same clips, and they differ. MPC-HC has a clear pattern for the BeginFrame/GetBuffer/Execute/EndFrame instructions. XBMC is not as consistent. I didn't find the XBMC code that makes those calls, can you please point me in the right direction?

- elupus - 2010-04-22 17:17

Technically that should not be a problem. Nothing should have been destroyed by that that the processor requires unless I've got some reference counting wrong (which i sort of doubt). But i suppose there could be a driver issue here that i'm not aware of (something similar was b0rk in vaapi with vdpau backend, but that was not the driver themself that had the issue)

- CrystalP - 2010-04-22 19:06

I see. I'll try forcing a blit immediatly after resources are freed, hopefully that'll raise the exception.

For fun, I tried to force the nVidia adapter in bitstream mode 2 - the mode that seems to have trouble in ffmpeg according to your comments.
On the Gladiator sample, nVidia in bitstream mode 1 or 2 gives exactly the same result: no green, slight smearing on the right hand side for a few seconds (until a key frame?), then perfect playback.

That's why I'm interested in finding where those BeginFrame/GetBuffer/Execute/EndFrame calls are made, because there doesn't seem to be something fundamentally wrong with bitstream mode 2 - at least on that sample. Is that the part handled by ffmpeg?

As you already mentionned, ATI only has bitstream type 2, so no comparison is possible there.

- elupus - 2010-04-22 19:09

bitstreamtype 2 is handing of abit more of the decoding to the hw. more in this case is very little, as it's only a few setup steps that are skipped.

- zad3717 - 2010-04-22 22:10

frotsen Wrote:Elupus do you have any clue why dxva with ati 5xxx series plays perfectly when you have the overlay osd on? se my post here http://forum.xbmc.org/showpost.php?p=518846&postcount=535

frotsen

I have the exact same issue m8 , never got dxva to work with any build Sad

got no idea what it is. did you fix yours??