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

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Windows (https://forum.kodi.tv/forumdisplay.php?fid=59)
+---- Thread: Initial native support for DXVA2 in SVN - Time to say goodbye to your firstborns (/showthread.php?tid=69306)



- elupus - 2010-04-19

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

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

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

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

Sounds like something getting released but then still used.


- CrystalP - 2010-04-22

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

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

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

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

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


- steelman1991 - 2010-04-23

elupus - quick question - I am running an unofficial build r29428 (fairly successfully), though I have a number of raw H264 remuxes (not encodes), which play but with a fair degree of pixelation - whereas others (again raw H264 remuxes) don't have any pixelation and play flawlessly. I know intially you stated that the playback of raw h264 was problematic (I guess it still is, but not to the same extent). Have you carried out any further testing and is this an expected behaviour at this stage of development.

Currently running Win7 x86 build, with an Nivida GT240 GFX.

Thanks


- CrystalP - 2010-04-23

Good news!

1. There is something broken in the drivers, or an unaccounted dependency. Using the processor after the decoder was released does cause the access violation, and that can easily be verified: take out the SAFE_RELEASE(m_decoder) from CDecoder::Close() and the exception goes away.
There is a good chance this is the cause for the hangs after playback, and it happens for both ATI and nVidia.

The decoder and the processor do not run on the same thread, so depending on scheduling, the number of processors/cores of the cpu, etc., the processor might be called after the decoder release, or not. Luckily it systematically happened to me under the debugger.


2. The lifecycle of the processor is a bit off - it's never released after playback. Could explain failures after playing a large number of clips.


I put some ideas in a patch to fix these two points. It works fine, but definitely needs review, as the rendering code is quite intricate and there might be better ways. On a new Trac ticket shortly.


- CrystalP - 2010-04-23

My bad, I created the DXVA Processor lifecycle issue when I fixed the exception. Better patch available on ticket #9116.


- CrystalP - 2010-04-24

Elupus, thanks for applying the patch.

I'm trying to run XBMC with the debug version of Direct3D9 (activated with the Direct X Control Panel of the SDK), hoping it would give clues to other DXVA issues. Unfortunately, DXVA mode doesn't engage because of an unspecified failure in GetDecoderDeviceGuids(). MPC HC continues running in DXVA mode, so there might be something going on with XBMC. Before I go deep in this, can someone verify that it's not only my computer?

P.


- FattyMcDirty - 2010-04-24

I installed the latest nightly and I exprience heavy stuttering with playing mkv content throught DXVA2 - no problem WITHOUT DXVA2.

I have Windows 7 32bit, AMD 4850e, NVIDIA 8200 HDMI, Audio through HDMI, AC3/DTS pass-through activated, VSync enabled

Here's a debug-log:
http://pastebin.com/EgaYFE0f

It doesn't drop frames.. it's just stuttering/flickering around Sad
Pls, any1 - help me Sad