Login at Kodi Home

davilla · 2013-01-12, 22:06

(2013-01-12, 21:46)Vatoe Wrote: I am not experiencing them either on 10.8.2 (RC3) - confirmed using the overlay info. I'm not using an intel GPU, perhaps this is the same for Ned? I did get the green line issue though when this popped up a little while back.

do you have refresh rate switching enabled or disabled ?

MeesterD · 2013-01-12, 22:42

Well... sorry to add to the confusion - but playback was fine last night ( and this afternoon) with hardware decoding enabled. Tonight, the problem has returned. I've rebooted my Mac to see if that fixed the issue but afraid not.

If I turn hardware decoding OFF smooth playback occurs. What it strange with decoding enabled, as soon as the overlay for pause stop ff etc comes to screen the dropped frames go away ; when that overlay disappears dropped frames come back again.

I have 'adjust display refresh rate' disabled.

This is a Mac Mini Mid 2011 with Lion, using Intel Graphics.

jingai · 2013-01-12, 23:54

I see the same thing re: the overlay -- no drops with it up.

~~Ned Scott~~ · 2013-01-13, 06:29

I am using a 2009 MBP with nvidia 9400M/9600M.

Vatoe · (This post was last modified: 2013-01-13, 07:34 by Vatoe.)

(2013-01-12, 22:06)davilla Wrote:
(2013-01-12, 21:46)Vatoe Wrote: I am not experiencing them either on 10.8.2 (RC3) - confirmed using the overlay info. I'm not using an intel GPU, perhaps this is the same for Ned? I did get the green line issue though when this popped up a little while back.

do you have refresh rate switching enabled or disabled ?

Refresh switch is on "Always". Render method is automatic and AV sync on audio clock. Oh, hardware decoding is also on.

jingai · (This post was last modified: 2013-01-13, 18:55 by jingai.)

Bisecting this now. First observation: the problem does not exist on the Dec 18 build, which seems includes the green line fix. As soon as I locate the build day where it broke, I'll bisect it down to the commit that broke it.

Would have done this earlier but with the holidays, my kid's birthday, etc, just hadn't had the time..

edit: Broke between 8d57808 and 46e045e. Bisecting now to find exact commit.

edit2: Haven't finished bisecting, but I'm going to wager it's this https://github.com/xbmc/xbmc/commit/aad9...b0c35d3e75. I'll try building from current head with that commit reverted when I'm done.

jingai · 2013-01-13, 21:08

Bisected down to commit aad9c2b being the culprit. Reverted that commit, rebuilt from 2d73753, and the primary problem (one frame drop every second) is gone for me. I still get an occasional dropped frame (roughly one per minute so far after watching for 10 minutes), as opposed to when it's set to software decoding and rendering, where I get none at all, even with that commit in place.

Since I have an Intel GPU and it's working without that commit, I can only guess that the logic for that condition is wrong (that is, the vendor isn't returning "Intel" on my machine, perhaps). If that code block is supposed to be executed with Intel GPUs, then something in there is not right. You guys probably know all of this already, but I'm trying to be thorough to be as helpful as I can. I'm a programmer, but I know basically nothing about CoreVideo/OpenGL/etc, so I figured I wouldn't make any assumptions.

MeesterD, and anyone else seeing this issue, if you'd like to try a build without that commit, I've uploaded it here. It's 64-bit built against the OSX 10.6 SDK. I'm definitely curious to see if you get the same results I do.

davilla etc, if you need logs for both or either build running on my machine, just let me know.

davilla · 2013-01-13, 21:36

what that does is force the green-line drawing mode. g_Windowing.GetRenderVendor().Find("Intel") is not working for some reason which is why it was forced

jingai · 2013-01-13, 22:52

Huh. Oddly I don't get the green line now whether that block executes or not, and I did see it before (some time prior to Dec 18ish). At least not on that movie (high bitrate, which is why I chose it to test with).

But yeah, that condition clearly isn't working right on this hardware.

jingai · 2013-01-14, 19:24

I take it back -- I do see the green line on another video.

MeesterD · 2013-01-16, 15:38

HI jingai,

Sorry not to respond sooner - I've been away for a couple of days. I'll try that build tonight when I'm home and feedback results. Hopefully it'll give davilla some more info to go on.

Many thanks

MeesterD · 2013-01-16, 20:52

Hi there jingai,

Tested using your 'special edition' and all appears to work as expected; I installed your package over top of my existing XBMC install, turned hardware endcoding back on and played some samples and are all silky smooth.

So it does seem that your tracked the issue down.

Regards.

jingai · 2013-01-17, 00:56

Yeah I think davilla has a grasp on what's going on but I'm not really sure what should be done to ultimately fix it. He probably has some ideas though Smile

davilla · 2013-01-17, 02:59

only thing I can think of is return of greenline code and those that have problems with it can disabled vda.

jingai · 2013-01-17, 03:09

To be honest the green line never bothered me much anyway (and I'm generally pretty picky). I only chimed in on the other thread because I noticed it.

I'd say if the solution (green line vs vda) is made clear to the user, that's probably fine.