[Riderzzz]

Hi,

probably have been asked alot, but couldnt find a answer to the question.

I have been playing around with some skins and fanart lately and came to the conclusion that when i have a skin with fanart enabled the movie stutters quite some more then if i have the fanart off. I also tried the DDS format but that didnt affect the movie playback much (but gui-wise a great improvement)

Now i was wondering, and i just wanna ask in this forum firdt because of all the appletv users, why is it that fanart slows down the playback process. I know the the ram gets loaded with the fanart picture and that there is less for the movie. But why is there less for the movie. Is it not possible when a movie starts playing xbmc gets kinda flushed and that there is no skin-related slowdown to the movie playback.

Its more like a random question because i know that the heavier skins or/and the skins with fanart on or not totally made for atv users. But i thinks the Gui responsesness is actually quite the same over all, just not the movie playback.

Im using atv on linux and osx, both the same problem when playing files.


Riderzzz

[davilla]

Hi,

probably have been asked alot, but couldnt find a answer to the question.

I have been playing around with some skins and fanart lately and came to the conclusion that when i have a skin with fanart enabled the movie stutters quite some more then if i have the fanart off. I also tried the DDS format but that didnt affect the movie playback much (but gui-wise a great improvement)

Now i was wondering, and i just wanna ask in this forum firdt because of all the appletv users, why is it that fanart slows down the playback process. I know the the ram gets loaded with the fanart picture and that there is less for the movie. But why is there less for the movie. Is it not possible when a movie starts playing xbmc gets kinda flushed and that there is no skin-related slowdown to the movie playback.

Its more like a random question because i know that the heavier skins or/and the skins with fanart on or not totally made for atv users. But i thinks the Gui responsesness is actually quite the same over all, just not the movie playback.

Im using atv on linux and osx, both the same problem when playing files.


Riderzzz

You have to think of both fanart load AND unload. When XBMC is starting video playback, that's the most critical time and anything that interrupts the main loop (xbmc uses a 'game loop' handler) will also interrupt video play back startup and video playback. Also the AppleTV is a pentium-m, one CPU. So there is no second CPU to off-load other threads that might be running.

Bottom line, if some thread takes longer than 1/fps amount of time, then a video frame will be late. Too many late frames and XBMC starts dropping frames and telling decoder to hurry up. That's when things start to get dicy. CrystalHD is pipelined, so the demux packet you send in, is NOT the decoded picture you get back. It's not uncommon that CrystalHD is many frames ahead in demux, you can see the in decoder OSD by looking at vq, if it's not near 99, then CrystalHD has many demux packets in it's pipeline. The issue becomes trying to limit what's in the pipeline while not starving the hw decoder. Total round trip demux -> hw decoder -> fetch picture is typically longer than frame time but when running pipelined it's not.

There are things that I'm thinking about that might resolve some issue but those wait until XBMC moves completely to the new CrystalHD API as I can't support both old and new API with these changes.

[Riderzzz]

You have to think of both fanart load AND unload. When XBMC is starting video playback, that's the most critical time and anything that interrupts the main loop (xbmc uses a 'game loop' handler) will also interrupt video play back startup and video playback. Also the AppleTV is a pentium-m, one CPU. So there is no second CPU to off-load other threads that might be running.

Bottom line, if some thread takes longer than 1/fps amount of time, then a video frame will be late. Too many late frames and XBMC starts dropping frames and telling decoder to hurry up. That's when things start to get dicy. CrystalHD is pipelined, so the demux packet you send in, is NOT the decoded picture you get back. It's not uncommon that CrystalHD is many frames ahead in demux, you can see the in decoder OSD by looking at vq, if it's not near 99, then CrystalHD has many demux packets in it's pipeline. The issue becomes trying to limit what's in the pipeline while not starving the hw decoder. Total round trip demux -> hw decoder -> fetch picture is typically longer than frame time but when running pipelined it's not.

There are things that I'm thinking about that might resolve some issue but those wait until XBMC moves completely to the new CrystalHD API as I can't support both old and new API with these changes.

Thanks for the response. I understand the mainline of it all. never had an it-education . I was just wondering about that unloading progress of the fanart. Would it not be possible that xbmc unloads the fanart first and when complete start the video-playback. Maybe these are just too simple thoughts, but i was just wondering.

[davilla]

Thanks for the response. I understand the mainline of it all. never had an it-education . I was just wondering about that unloading progress of the fanart. Would it not be possible that xbmc unloads the fanart first and when complete start the video-playback. Maybe these are just too simple thoughts, but i was just wondering.

Yes, but it does not work that way The other thing would be to dump the game loop concept (it's what we call an xbox'ism) and re-factor a lot of code. We keep talking about this but no one was jumped at doing the re-factor.

[Riderzzz]

Yes, but it does not work that way The other thing would be to dump the game loop concept (it's what we call an xbox'ism) and re-factor a lot of code. We keep talking about this but no one was jumped at doing the re-factor.

allright, alot of genious talk here. I hope this xbox'ism will get out some day, and we have a proper code :p

But always good to know it can only go better.

Btw, davilla, what will be your next big project now the crystal drivers are kinda out again? hint hint