•  Previous
  • 1
  • 2
  • 3(current)
  • 4
  • 5
  • 13
  • Next 
 
Thread Rating:
  • 1 Vote(s) - 5 Average
Mac OS X - [Mac Mini] [v17 Nightly] Choppy Video Playback
#31
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.
Reply
#32
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...
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#33
(2016-09-28, 23:00)jingai Wrote: 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.
How to post a debug log ; MacOS acces the hidden userdata folder ; How to post a question ; How to fix gatekeeper issues
Reply
#34
(2016-09-29, 07:15)Memphiz Wrote: 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?

(2016-09-29, 07:15)Memphiz Wrote: 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.

(2016-09-29, 07:15)Memphiz Wrote: 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.
Reply
#35
(2016-09-29, 07:20)Walt74 Wrote:
(2016-09-28, 23:00)jingai Wrote: 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.
Reply
#36
(2016-09-29, 15:15)jingai Wrote:
(2016-09-29, 07:20)Walt74 Wrote:
(2016-09-28, 23:00)jingai Wrote: 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.
How to post a debug log ; MacOS acces the hidden userdata folder ; How to post a question ; How to fix gatekeeper issues
Reply
#37
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...
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#38
Memphiz, i can test on a mac mini 2011, i mac 2011 and a mac book air 2011 and a macbook air 2012.
How to post a debug log ; MacOS acces the hidden userdata folder ; How to post a question ; How to fix gatekeeper issues
Reply
#39
(2016-09-30, 07:23)Memphiz Wrote: 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.

(2016-09-30, 07:23)Memphiz Wrote: 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.
Reply
#40
Yes it only seems to hit some hardware constellations - i couldn't reproduce it either.
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#41
[deleted]
Reply
#42
you should only log the decode time if the result is 0 i guess ... not sure - i'll ask someone else Smile - in principal i think you got it righ.
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#43
[deleted, will repost with new builds in a little bit]
Reply
#44
measurements need to be placed around avcodec_decode_video
https://github.com/xbmc/xbmc/blob/master...g.cpp#L648
Reply
#45
I'll do that and rebuild tomorrow. Have family obligations today.
Reply
  •  Previous
  • 1
  • 2
  • 3(current)
  • 4
  • 5
  • 13
  • Next 
 
Thread Rating:
  • 1 Vote(s) - 5 Average



Logout Mark Read Team Forum Stats Members Help
[Mac Mini] [v17 Nightly] Choppy Video Playback51