[jingai]

Memphiz, I applied your changes in your 422YpCbCr8_iosurface branch to current master and the problem seems to have been fixed on my MacBook Air. Checking on my Mac mini in a few minutes, but I suspect it will work since it's the same generation CPU.

edit: Problem is gone on the Mac mini too. Refresh rate switching doesn't appear to be working, but looking into that now.

edit2: Yeah, refresh rate switching isn't working. It says it's doing it, but it's not actually happening. Here is the debug log -- look around 17:33:33.

[Memphiz]

We would need to time the decoding and the rendering with and without my change to see what the cause is really. The problem is that this needs a ffmpeg patch and is still something wrong with fullscreen on el capitan which puts unusual high load on the cpu.

For reference:

http://stackoverflow.com/questions/27758...de-on-os-x

I am still in the process of moving into my new flat at this moment - my hands are bound so to say...

Time the create texture and upload methods here:

https://github.com/Memphiz/xbmc/blob/c76...rVTBGL.cpp

For decoding - log the time needed here:

https://github.com/Memphiz/xbmc/blob/c76...g.cpp#L608

For rendering i don't know if the first codeplace is enough though

Gotta run...

[Waltman]

Memphiz, I applied your changes in your 422YpCbCr8_iosurface branch to current master and the problem seems to have been fixed on my MacBook Air. Checking on my Mac mini in a few minutes, but I suspect it will work since it's the same generation CPU.

edit: Problem is gone on the Mac mini too. Refresh rate switching doesn't appear to be working, but looking into that now.

edit2: Yeah, refresh rate switching isn't working. It says it's doing it, but it's not actually happening. Here is the debug log -- look around 17:33:33.

Jingai, should i also test this build on my Mac Mini ? just let me know, including what you want tested.

[jingai]

We would need to time the decoding and the rendering with and without my change to see what the cause is really. The problem is that this needs a ffmpeg patch

What patch are you waiting on? Is there discussion about it somewhere?

and is still something wrong with fullscreen on el capitan which puts unusual high load on the cpu.

For reference:

http://stackoverflow.com/questions/27758...de-on-os-x

I just woke up, so I'll look at this in a bit, but it looks like there is a workaround there. I assume it's already been tried? If not, I can look into it.

Time the create texture and upload methods here:

https://github.com/Memphiz/xbmc/blob/c76...rVTBGL.cpp

For decoding - log the time needed here:

https://github.com/Memphiz/xbmc/blob/c76...g.cpp#L608

I can do this within the next couple of days. I'll post back with the logs.

[jingai]

Memphiz, I applied your changes in your 422YpCbCr8_iosurface branch to current master and the problem seems to have been fixed on my MacBook Air. Checking on my Mac mini in a few minutes, but I suspect it will work since it's the same generation CPU.

edit: Problem is gone on the Mac mini too. Refresh rate switching doesn't appear to be working, but looking into that now.

edit2: Yeah, refresh rate switching isn't working. It says it's doing it, but it's not actually happening. Here is the debug log -- look around 17:33:33.

Jingai, should i also test this build on my Mac Mini ? just let me know, including what you want tested.

There's not really anything to test -- all I did was apply Memphiz's 422 renderer patches. I'd assume this doesn't work on all machines or something.

I can provide a build if you just want something that 'works' for now, though.

[Waltman]

Memphiz, I applied your changes in your 422YpCbCr8_iosurface branch to current master and the problem seems to have been fixed on my MacBook Air. Checking on my Mac mini in a few minutes, but I suspect it will work since it's the same generation CPU.

edit: Problem is gone on the Mac mini too. Refresh rate switching doesn't appear to be working, but looking into that now.

edit2: Yeah, refresh rate switching isn't working. It says it's doing it, but it's not actually happening. Here is the debug log -- look around 17:33:33.

Jingai, should i also test this build on my Mac Mini ? just let me know, including what you want tested.

There's not really anything to test -- all I did was apply Memphiz's 422 renderer patches. I'd assume this doesn't work on all machines or something.

I can provide a build if you just want something that 'works' for now, though.

Yes, that would be Nice. Thank you.

[Memphiz]

Its basically this commit in my branch - https://github.com/Memphiz/xbmc/commit/6...956c9c0842

Which results that this ffmpeg tree from me is pulled with this patch in it:

https://github.com/Memphiz/FFmpeg/commit...beaa7a58d2

Atm ffmpeg has a hardcoded frame format which comes out from the vtb decoder. The whole branch simply changes this format and does the needed color conversion via a shader. The problem is, that this is not logical to me. Configuring the vtb decoder to output already the needed format should be faster then getting the wrong formt first and convert it afterwards via shader.

I can not upstream this yet as there is way to less feedback with different apple gpus. And also the better patch would be to make this configurable in ffmpeg which i over my head.

First we need to see what is slower or faster here ... The decoding or the rendering which involves the color conversion.

Thx for your support on this jingai ... much appreciated.

About the fullscreen problem - fernetmenta tried to resize the fullscreen and confirmed that it fixes the problem. He only saw it on his external hdmi screen though. Not sure if he pushed this to github somewhere...

[Waltman]

Memphiz, i can test on a mac mini 2011, i mac 2011 and a mac book air 2011 and a macbook air 2012.

[jingai]

Its basically this commit in my branch - https://github.com/Memphiz/xbmc/commit/6...956c9c0842

Which results that this ffmpeg tree from me is pulled with this patch in it:

https://github.com/Memphiz/FFmpeg/commit...beaa7a58d2

Atm ffmpeg has a hardcoded frame format which comes out from the vtb decoder. The whole branch simply changes this format and does the needed color conversion via a shader. The problem is, that this is not logical to me. Configuring the vtb decoder to output already the needed format should be faster then getting the wrong formt first and convert it afterwards via shader.

I can not upstream this yet as there is way to less feedback with different apple gpus. And also the better patch would be to make this configurable in ffmpeg which i over my head.

First we need to see what is slower or faster here ... The decoding or the rendering which involves the color conversion.

Thanks for the explanation. I have a clearer understanding of the problem now and why you want to time it. I'll get on that as soon as I can and provide the build here so you can get logs from others as well.

About the fullscreen problem - fernetmenta tried to resize the fullscreen and confirmed that it fixes the problem. He only saw it on his external hdmi screen though. Not sure if he pushed this to github somewhere...

I don't think I'm seeing this problem here. When playing that same movie and running top in the background, I never see Kodi use more than ~12% CPU on my MacBook Air. I've checked this on both the internal display and my external DisplayPort-connected display.

[Memphiz]

Yes it only seems to hit some hardware constellations - i couldn't reproduce it either.

[jingai]

[deleted]

[Memphiz]

you should only log the decode time if the result is 0 i guess ... not sure - i'll ask someone else - in principal i think you got it righ.

[jingai]

[deleted, will repost with new builds in a little bit]

[FernetMenta]

measurements need to be placed around avcodec_decode_video
https://github.com/xbmc/xbmc/blob/master...g.cpp#L648

[jingai]

I'll do that and rebuild tomorrow. Have family obligations today.