High CPU/stuttering on high bitrate X.264 MKV

[mikeemouse]

Software
XBian version: 1.0 Beta2
XBMC version: 12.2 Git:20130916-091cb29 (Compiled: Oct 2 2013)
Overclock settings: High (tested - stable)

Hardware
Power supply rating: Nokia AC16X 5V/1A
RPi model (model A/B 256mb/512mb): B/512
SD card size and make/type: HAMA GOLD SDHC CARD 8GB CLASS 10
Network (wireless or LAN): 500mbit powerline (actual throughput tested using dd over SMB on Pi at 90mbit). SMB and NFS both tried, both show the problem. Server is Windows Home Server, CPU load ~3% while serving files.
Connected devices (TV, USB, network storage, etc.): Pi -> Yamaha AV receiver over HDMI -> TV

Logile
Link to logfile(s): http://pastebin.com/ZAmi2bjz

Problem description:
Playback stutters during playback of high bitrate files (only MKV tested). Lower bitrate files don't cause problems.

How to reproduce:

Play high bitrate mkv. Example:

Star Wars Blu-ray remux mkv
Video: AVC High L4.1 avg bitrate 33mbit, peak 42.1mbit
Audio: DTS 5.1 1509kbit

---

config.txt

#initramfs initramfs.gz 0x00a00000
gpu_mem_512=256
gpu_mem_256=128
initial_turbo=1
decode_MPG2=<deleted>
disable_overscan=1
hdmi_group=1
hdmi_mode=16
disable_splash=1
arm_freq=950
core_freq=450
sdram_freq=500

hdmi_force_edid_audio=1
over_voltage=2
decode_WVC1=<deleted>

[rikardo1979]

im not sure but im afraid that such a bitrate might be a bit too much for RPi together with DTS, cant really test.if you can cut a small part of it just for test and share in like gdrive or dropbox so someone else can test

[mikeemouse]

I found switching to NFS does make an improvement, but it's not perfect.

Here's a sample

https://www.dropbox.com/s/p70o1ssz4upve5z/Sample.mkv

[freem@n]

(12th Dec, 2013 08:11 AM)mikeemouse Wrote:  Network (wireless or LAN): 500mbit

How did you get 500MBit LAN connection? the Pi has only 100MBit. Furthermore Network and USB controller have to share bandwidth.
but back to your problem.
I guess DTS Passthrough to your AVR is enabled. otherwise it would explain the high CPU load because of decoding which can be pretty slow.
do you have any other services running in the background? (downloading/extracting/update/etc)

[rikardo1979]

(12th Dec, 2013 06:37 PM)freem@n Wrote:  

(12th Dec, 2013 08:11 AM)mikeemouse Wrote:  Network (wireless or LAN): 500mbit

How did you get 500MBit LAN connection? the Pi has only 100MBit. Furthermore Network and USB controller have to share bandwidth.
but back to your problem.
I guess DTS Passthrough to your AVR is enabled. otherwise it would explain the high CPU load because of decoding which can be pretty slow.
do you have any other services running in the background? (downloading/extracting/update/etc)

he doesnt achieve 500mega on RPi as you can read, he just use the power line adaptors with this 500 theoretical speed performance and his actual speed to RPi is 90
Also check what bitrates of playing videos he mentioned, I think that it might be just too much for it.

He also posted a link to sample of the file so please if someone can test that and report back with findings
-thx-

[IriDium]

Well that sample didn't play properly with vlc on my main PC with duel cores, so the chances of it playing on the RPi are very slim.

[mikeemouse]

(13th Dec, 2013 02:06 AM)IriDium Wrote:  Well that sample didn't play properly with vlc on my main PC with duel cores, so the chances of it playing on the RPi are very slim.

under 5% CPU here using Media Player Classic. I think something must be wrong with the setup on your PC if it doesn't play.

[rikardo1979]

(13th Dec, 2013 02:57 AM)mikeemouse Wrote:  

(13th Dec, 2013 02:06 AM)IriDium Wrote:  Well that sample didn't play properly with vlc on my main PC with duel cores, so the chances of it playing on the RPi are very slim.

under 5% CPU here using Media Player Classic. I think something must be wrong with the setup on your PC if it doesn't play.

you are right, it should play fine on such config. It plays fine on my Zenbook but its new i7 but still on Core2 should be piece of cake.
But we need someone to test on RPi its pretty useless to test on other platforms

[rikardo1979]

I have just found something really odd as I was testing the file and searching for clues. On my Zenbook playing the file with VLC or MediaPlayerClasic when you look to file/codec info it showing that the audio is DTS 5.1 but when I tried to play it on same laptop but with Windoze XBMC the file is detected as DTS 6.1 ???

[rikardo1979]

so after these finding it make me think that there is something just not right with your media rips, where PC's can handle this as it has a lots of power but for RPi is just too much to do so

[mikeemouse]

6.1 is correct, the main audio stream is a DTS-ES Discrete 6.1 track @ 1509 kbit

DTS Discrete is fully backwards-compatible, so if you don't support it, it will be seen as a 5.1 track.

There are some other tracks:

AC3 5.1 448kbit audio described
AC3 2.0 224kbit commentary 1
AC3 2.0 224kbit commentary 2

But none are substitutes for the ES track.

[mk01]

@micymuse,

played on my RPI (920,420,500) with SW decoding, don't have AVR at hand currently to test passthrough.

tested from xbmc's nfs source directly (this would be nfs3) and from locally mounted same export as with nfs4 (rsize=128k,wsize=32k). xbmc is pre buffering quite long and shutter 2x in the first 5s, local mount will shutter 1x in the first 5s.

you have to find out if this is not still the resemblance of ES/DTS issues with fw and passthrough and whatsoever.

what you can check yourself is to update to the latest versions of kernel&fw&xbmc available what is (not considering gotham) :

Code:

xbian-package-firmware    1.4.10
xbian-package-kernel    1.3-6.3
xbian-package-xbmc    2.9-10.17

but this won't make much difference I think.