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

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

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

- FattyMcDirty - 2010-04-25

EDIT:
I sorted it out... it wasn't XBMC's fault.. I have a system called AMBX running, which is an usb-ambilight-system from Philips. This seems to bork the playback within XBMC. Unplugging it moves all issues right away.. 1080p playback is no smooth as hell with about 6% cpu-load and no video-jerking Wink

Sorry guys... I wouldn't have thought that this system causes SUCH problems.. i knew the cpu kinda suffers from it.. but I didn't expect those video-jerks to be caused by it Sad

- oldpainless - 2010-04-25

FattyMcDirty Wrote:EDIT:
I sorted it out... it wasn't XBMC's fault.. I have a system called AMBX running, which is an usb-ambilight-system from Philips. This seems to bork the playback within XBMC. Unplugging it moves all issues right away.. 1080p playback is no smooth as hell with about 6% cpu-load and no video-jerking

Sorry guys... I wouldn't have thought that this system causes SUCH problems.. i knew the cpu kinda suffers from it.. but I didn't expect those video-jerks to be caused by it

Glad you have it sorted... Big Grin

I've checked every process that's was running on my rig, and cant see anything amiss Eek

Oh, well...looks like I stay with my pre-merge build for the mo. But, it is something that is effecting both dvd and dsplayer for some people.

K

- SlaveUnit - 2010-04-25

Yeah it plays smooth on mine too. Just for a crazy shot...do you have "enable other programs to control XBMC" unchecked in your settings?

- oldpainless - 2010-04-25

SlaveUnit Wrote:Yeah it plays smooth on mine too. Just for a crazy shot...do you have "enable other programs to control XBMC" unchecked in your settings?

Not sure...will check.

K

- FattyMcDirty - 2010-04-25

SlaveUnit Wrote:Do you have "enable other programs to control XBMC" unchecked in your settings?

Yes.. for my Remote Control.. because I've got EventGhost running for recognizing the RC commands..

- CrystalP - 2010-04-25

I started looking into the refresh rate switching & DXVA. The problem is linked to the D3D device resets and various parts of XBMC not completely stopping before the device is back to a usable status - and on top of that, sometimes XBMC gets stuck in an infinite loop where the device can't be brought back to life.

To avoid this, first I think we should minimize the number of device resets and refresh rate changes. I have a patch almost ready for that. That will help mostly fake fullscreen, as it doesn't require device resets. It already works pretty well with DXVA.

Then, tackle the true fullscreen refresh rate changes. They require a device reset and they're not 100% reliable for me, even for non-DXVA playback.

With good refresh rate switching in all situations, I hope it'll be easier to understand the DXVA specific problems.

What do you think elupus?

- sebak - 2010-04-25

I've got the same issue as oldpainless with build from r29466 (from 2 days ago I believe)

It looks like it's going 2 steps forward & one step back, if you know what I mean.

Every few seconds it shows a frame it has already shown.

It makes the movie completely unwatchable.

Furthermore, I get pixelation issues when fast forwarding, but that's a known problem I believe.

Win 7 32bit - geforce 8600m - x264 mkv files streamed from smb source, doesn't seem to happen with local files and I'm sure my network connection is more than fast enough.

- oldpainless - 2010-04-26

SlaveUnit Wrote:Yeah it plays smooth on mine too. Just for a crazy shot...do you have "enable other programs to control XBMC" unchecked in your settings?

Slaveunit,

Thanks for the tip...but made no difference. Have now tried local and files over smb - still the same issue.

Thanks anyway.

K

- ashlar - 2010-04-26

CrystalP Wrote:I started looking into the refresh rate switching & DXVA. The problem is linked to the D3D device resets and various parts of XBMC not completely stopping before the device is back to a usable status - and on top of that, sometimes XBMC gets stuck in an infinite loop where the device can't be brought back to life.

Could I humbly ask that while this aspect of XBMC is put under the mangnifying glass some thought is given to starting video playback only *after* the refresh rate switch has happened?

The majority of HDMI enabled TVs take several seconds to lock on the changing signal. The result, for me, is that on my Pioneer plasma I get the first... two/three seconds of audio with no video.

- Sinnocence - 2010-04-26

sebak Wrote:I've got the same issue as oldpainless with build from r29466 (from 2 days ago I believe)
...
Every few seconds it shows a frame it has already shown.
...
x264 mkv files streamed from smb source, doesn't seem to happen with local files

I'm seeing this exact same behaviour on an sshc nightly build, though I've not tried with local files yet. Win 7 x64, ASRock 330 ION + a myriad of mkvs with every (?) combination of playback options from settings.

- FattyMcDirty - 2010-04-26

ya.. using sshc's builds, too.. but as for me, those things are sorted out now due to my ambx thingy.. but i'd still be interested in the cause of that problem. because it WAS working some builds before WITH ambx enabled.. and i wouldn't like my ambx-system to be covered with dust from now on due to these strange errors Sad

so a fix would be appreciated a lot!

- SlaveUnit - 2010-04-26

People with the problem, you can help the devs a lot by trying to narrow down what chage in the code screwed things up. The way I do it is to get the nightly builds then narrow down what one worked and what one didnt. Then look in the in the timeline and try to see what changes made between them that might effect the problem. This process is simple enough to where anyone can do it and it really saves the devs time.

Or if you dont want to guess, compile yourself and figure out exactly what svn screwed it up. Smile

- oldpainless - 2010-04-26

SlaveUnit Wrote:People with the problem, you can help the devs a lot by trying to narrow down what chage in the code screwed things up. The way I do it is to get the nightly builds then narrow down what one worked and what one didnt. Then look in the in the timeline and try to see what changes made between them that might effect the problem. This process is simple enough to where anyone can do it and it really saves the devs time.

Or if you dont want to guess, compile yourself and figure out exactly what svn screwed it up.

Man, total respect for what you are trying to do...but, that's a tough call. Users are not really going to know what bit of code has changed what.

Like I said, for me, pre-merge was working fine, and more than willing to help the dev with system info/samples etc.

and - Or if you dont want to guess, compile yourself and figure out exactly what svn screwed it up. Smile

, - is that really helpful?

I might be wrong, but there seems to be a high number of people with modern nvidia cards that have reported the issue?

K

- SlaveUnit - 2010-04-26

Yeah, for me it has been very helpfull. A while back I had an issue where certain DVD files that would stutter. Even when played local. So I narrowed it down to the range of SVNs that caused it and reported that in the thread. Then no one replied so I said well let me figure out exactly what svn ruined it. So I read the wiki on how to compile and started doing one by one until I got to the one that ruined it. So once I reported what svn ruined it, it was fixing within a day or so.

I guess it depends on how impatient you get. I get bad anxiouty problems at times and I cant just wait for a dev to reply if I know I can accelerate the troubleshooting. Smile

Of course it's not for everything but the more people that can help with things like that the more time it leaves devs to work on other issues or further development.

At a bare minimum you can narrow it down to a range of what svn nightly broke it and report that. Just report what was the last nightly that played the file back correctly and what one after that it stopeed working in. Always try to report the svn numbers. Not just "pre-merge or newest build" Then at least it can be narrowed down to about 25-50 different commits. I have dedicated machines for XBMC but I also run it on my main desktop just for testing and playing with things before commiting them to my dedicated boxes.

And trust me, im no programmer or dev. But when you have stuttering like this looking at the timeline code titles isn't rocket science. You look for DXVA changes, usually by elupus at this pont. Thats a good starting point.

- SlaveUnit - 2010-04-26

So I was given a sample from steelman. I see the "two steps forward, one step back" issue now that sebak and steelman see. Here is the sample if anyone else wants to test for themselves (hope you dont mind steelman). http://www.mediafire.com/?1w2y2zzmnbq

I will try to look more into the causing issue today or possibly tomorrow (time permitting).

EDIT: Actually thinking about that sample. When I received it this morning I did try it in ffplay (the ffmpeg player) and saw the same results.
sebak and oldpainless,

Did these files that are jumpy ever playback fine for you? Im sure you probably told me I just cant remember that answer.