+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Kodi related discussions (https://forum.kodi.tv/forumdisplay.php?fid=6)
+--- Thread: Smoothvideo branch (/showthread.php?tid=46091)
- neurosis13 - 2009-04-14
kees1869 Wrote:The mod one prevents the display from going to standby while XBMC is running. I have a dual display setup and when my PC display goes into standby it also disables XBMC on my TV (which is annoying when watching a movie).
i noticed this behaviour, very good idea.
thumbs up.
- alanwww1 - 2009-04-15
@bobo1on1
What is this scheduling workaround for multithreading ?
http://trac.xbmc.org/changeset/19466
Does it solve the Intrepid multithreaded video decoding problem ?
Would be awsome !
- bobo1on1 - 2009-04-15
It balances the cpu load but I've never had 1080p decoding without the bug so I can't say for sure, it's an attempt to fix it.
- alanwww1 - 2009-04-15
bobo1on1 Wrote:It balances the cpu load but I've never had 1080p decoding without the bug so I can't say for sure, it's an attempt to fix it.
The bug was not there on Hardy. Only on Intrepid and Jaunty. Somehow the entrophy CABAC patch xbmc uses to make semi multithreading for x264 don't work properly with newer Ubuntu libs.
Thanks for trying to solve this problem. I will test it tonight.
- LolitaRainking - 2009-04-15
I just wanted to let you know that on my rig (c2d 2.16 with radeon HD4550) this runs perfect now. Yesterday I accidentaly started the ordinary branch, and let me tell you - boy, that's like night and day. I love this branch!!! I'd kiss you if I got a chance, and I'm straight!
- noeikujoo - 2009-04-16
alanwww1 Wrote:@bobo1on1This scheduling workaround solved the Intrepid multithreaded decoding problem on my HTPC (c2d 2.4 with GeForce 8400GS). I tested yesterday new version and h264 1080p MKVs runs smoothly at normal framerate and core loads were almost even, framedrops were the only ones generated at the begining of the playing but not increasing at all while the whole of the movie. Now I can run XBMC without VDPAU. I noticed that playback is much more smoother with software decoding than with VDPAU. MKVs with embedded subtitles and auto refresh rate began to work when I disabled VDPAU.
What is this scheduling workaround for multithreading ?
http://trac.xbmc.org/changeset/19466
- alanwww1 - 2009-04-16
I only tested one 1080p file with the scheduling workarund, but is only helping to share the loads between the two cores, but the loads don't go higher than max 65-65% for eighter of the cores i have the same amount of framedrops as without the workaround.
On hardy with the same file i have 90-90 % core utilization with no framedrops. I think the problem is not the utlization sharing of the two cores it is more the problem of having the decode process sequential. The two threads are waiting each other to finish. This is why we can not utilize the whole of the cpu times. This is why so far it does not matter if the two threads are waiting for each other on the same core or on a different core.
It is just like if you try a 100% one core written code on a quad core processor you will surely not see more than 25% CPU utilization per core.
On xbmc we only see more than 50-50% because we have some other running processes like audio decodeing and ubuntu base daemons.
So i think we should be dig more into the code of the xbmc cabac patch for ffmpeg what's causing this behaviour.
About vdpau smoothness i realized that with latest nvidia driver and strict binding turned on in advancedsettings.xml i have an almost perfect playback, but when i turn on any .SRT subtitles it starts to stutter. I have to make more tests to confirm this. I will make some test files so everyone could debug this situation. I think it is more the problem of the vdpau decoding than the smoothvideo branch.
- noeikujoo - 2009-04-16
I tested many 1080p files and the loads went higher than 65% on my setup. I got only three to five dropped frames when playing "killa sample". The loads were not still even (70% and 97%), when frames were dropped, but more even as before workaround. Other tested 1080p files plays fine without dropped frames. Before workaround frames were dropped almost all h.264 1080p files if not using VDPAU.
- alanwww1 - 2009-04-16
noeikujoo Wrote:I tested many 1080p files and the loads went higher than 65% on my setup. I got only three to five dropped frames when playing "killa sample". The loads were not still even (70% and 97%), when frames were dropped, but more even as before workaround. Other tested 1080p files plays fine without dropped frames. Before workaround frames were dropped almost all h.264 1080p files if not using VDPAU.
I make som efurther testing today. I tried a high bitrate 20-30mps Dark Knight BD rip, which plays just fine iwth Hardy around 90-90 % Core utilization, but with Jaunty i can't get to work without dropped frames. I will check it without audio resampling enabled, because i think it could also take ups some CPU time.
- sensei73 - 2009-04-16
tips --=>if you guys run with a dedicated htpc, just stick with hardy!!! It's working really great here!
- noeikujoo - 2009-04-16
alanwww1 Wrote:I make som efurther testing today. I tried a high bitrate 20-30mps Dark Knight BD rip, which plays just fine iwth Hardy around 90-90 % Core utilization, but with Jaunty i can't get to work without dropped frames. I will check it without audio resampling enabled, because i think it could also take ups some CPU time.I noticed that you are using Jaunty and I'm running XBMC on Intrepid. Maybe there is some difference between Jaunty and Intrepid on Core ulitization?
What revision of XBMC smoohtvideo you are running? Yesterday I tested earlier downloaded 19466 revision. Just a moment ago I noticed that newer 19485 revision has some modifications on "thread scheduling workaround" -> http://trac.xbmc.org/changeset/19485/branches/smoothvideo
- alanwww1 - 2009-04-16
noeikujoo Wrote:I noticed that you are using Jaunty and I'm running XBMC on Intrepid. Maybe there is some difference between Jaunty and Intrepid on Core ulitization?
What revision of XBMC smoohtvideo you are running? Yesterday I tested earlier downloaded 19466 revision. Just a moment ago I noticed that newer 19485 revision has some modifications on "thread scheduling workaround" -> http://trac.xbmc.org/changeset/19485/branches/smoothvideo
I think my revision was higher than this modification. I will test more tonight when i get home.
- wizzle - 2009-04-17
Hey guys, I've got a quick compiling question. I'm a little unclear of the correct workflow: Should I be merging the Smoothvideo branch with the main linuxport prior to compiling? Or will it already be in sync with the linuxport changes?
- bobo1on1 - 2009-04-17
I keep it in sync every few days or so.
- ERamseth - 2009-04-20
I plan on testing out the smoothvideo branch this evening when I get home from work but I have some (dev/debug newbie) questions...
[I know this isn't really the place for these but I didn't find a central place with this info.]
- Is there a way to output to a log or screen the exact # or % of dropped frames?
- Is there a way to see CPU utilization(s) on screen while playing a file in XBMC? (I thought the "o" key for "codec info" would do it, but this just causes a crash on my rig as of last night)
- How do I grab the branch exactly (guessing svn co http://xbmc.svn.sourceforge.net/svnroot/xbmc/branches/smoothvideo)?
- Do I need to merge smoothvideo branch with linuxport branch as mentioned above? If so/not, why/why not? Are there advantages/disadvantages to merging/not merging?
- Do I need strictbindings (saw references to it)? If so, how do I enable (also saw references on how to enable strictbindings, but some conflicted with others... just wanted to be sure)?
Side note: Thanks for all the hard work. Hopefully smoothvideo can help with my problems as described here: http://forum.xbmc.org/showthread.php?tid=49235