Kodi Community Forum

Hi

I am a long time XBMC enthusiast and really like the program to playback HD content on my iMac (2.4 Ghz Core 2 Duo, August ’07, OS X 10.6.4).
So far I’ve not had any problems with video playback until yesterday I decided to try out the latest nightly build. The CPU usage graphs of both the official Camelot release and the latest nightly build are shown below. Both are playing the same movie scene in an mkv with h264 video. During both measurements no other applications than XBMC were open. As you can see Camelot equally distributes the decoding over both CPU cores all the time, even when the h.264 stream goes to 20 Mbps (before the middle of the graph). The nightly build does not equally distribute decoding resulting in one of the CPU cores reaching its maximum capacity (alternating). This of course resulted in stuttering video playback and lots of lost frames in the nightly build while Camelot was fluent and without problems.
I have also done the same test with the latest version of VLC (1.1.0) and playback was also fluent and no lost frames.
It’s a bit strange that an older version of XBMC handles high bitrate video very well, while a newer version doesn’t. Is the development team aware of this issue and is it going to be solved before the next official release?
Thanks for your time.

camelot:



nightly build r31755:

Camelot used an ffmpeg hack for multi-threading. That hack is no longer available with the current ffmepg source code.

A side note, that ffmpeg hack also by-passed inner-loop deblocking of h.264 which resulted in slightly less quality on the decoded image and faster decoding. Not many users noticed it. There's an advanced settings that could restore this, skip-loop filter or something like that. Set this to 8.

Thanks for the quick reply.

I've tried what you said, even put it on higher values than 8 (tried 16 and 32) but it doesn’t seem to change anything. I still get one CPU core completely maxed out.
Just to make sure I didn’t do anything wrong:
I made this file: /Users/<username>/Library/Application Support/XBMC/userdata/advancedsettings.xml containing this:

<advancedsettings>
<skiploopfilter>8</skiploopfilter>
</advancedsettings>

and then of course restarted xbmc

If you look at the ffmpeg changelog it lists “slice-based parallel H.264 decoding” as an added feature in v0.5. So I assume they removed this in v0.6 but this removal is not listed under the changelog of v0.6. Isn’t it possible to check if this feature is still there and if it is to use it?

I hate Apple by the way for not adding VDADecoder support for Macs released before the first Macbooks with the NVIDIA 9400M graphics card.

Doesn't anyone know how to bring this multithreaded decoding back? Since the computer industry has been fully evolving to dual or even quad core processing over the past 4 years it's almost unbelievable that the programmers of ffmpeg decided to go back to the single core era.
And what about using Grand Central Dispatch on OS X? Or is this also something the ffmpeg community has to do?

ffmpeg never included the multi-thread decoding. it was a third-party hack of a patch we applied. ffmpeg did tons of updates. patch broke. nobody cba to update it.

http://gitorious.org/ffmpeg/ffmpeg-mt

they will surely appreciate all the help you are obviously willing to offer!