Video is choppy on cubox-i

[321liftoff]

With all packages up-to-date even with the devel source, playing videos: xvid, MPEG-2, and h.264, are choppy. Packages being used include:

xbian-package-a2dp/stable 1.0 armhf xbian-package-cec/staging 1.1.6-3 armhf xbian-package-cec-6q/staging,now 2.1.7-3 armhf [installed] xbian-package-config-shell/stable,now 2.1.7-4 armhf [installed,automatic] xbian-package-config-xbmc/stable,now 1.1.8-1 armhf [installed,automatic] xbian-package-couchpotato/stable 2.0.7 armhf xbian-package-development/stable 1.0 armhf xbian-package-download/stable 3.0 armhf xbian-package-firmware/devel 1.4.16 armhf xbian-package-firmware-6q/staging,now 1.6.0-6 armhf [installed] xbian-package-headphones/stable 1.1.0-1 armhf xbian-package-imx-lib-6q/staging,now 1.0.1a armhf [installed,automatic] xbian-package-initramfs-tools/stable,now 1.3.4-10b armhf [installed,automatic] xbian-package-kernel/devel 1.3.7-3 armhf xbian-package-kernel-6q/staging,now 1.3.11 armhf [installed] xbian-package-kernel-headers/devel 1.3-6.11 armhf xbian-package-kernel-headers-6q/devel 1.3.10-4 armhf xbian-package-libfslaaccodec-6q/staging 1.0.0 armhf xbian-package-libfslcodec-6q/staging,now 1.0.0 armhf [installed,automatic] xbian-package-libfslparser-6q/staging,now 1.0.0 armhf [installed,automatic] xbian-package-libfslvpuwrap-6q/staging,now 1.0.0-2 armhf [installed,automatic] xbian-package-libshairport/stable 1.0-1 armhf xbian-package-libtag/stable,now 1.0-3 armhf [installed,automatic] xbian-package-lirc/stable,now 1.4-8.8 armhf [installed,automatic] xbian-package-maraschino/stable 1.0 armhf xbian-package-nzbget/stable 12.0 armhf xbian-package-rasp-switching/stable 1.0.1 armhf xbian-package-repo/stable,now 1.0.0 armhf [installed] xbian-package-repo-pilight/stable 1.0.0 armhf xbian-package-samba/stable,now 2.0.0-4 armhf [installed,automatic] xbian-package-shairplay/stable 1.0.5-1 armhf xbian-package-shairplay-6q/staging,now 1.0.3-1 armhf [installed,automatic] xbian-package-sickbeard/stable 1.2 armhf xbian-package-sickbeard-tpb/stable 1.1 armhf xbian-package-splash/stable,now 2.0.4-3 armhf [installed,automatic] xbian-package-transmission/stable 2.82 armhf xbian-package-tvheadend/stable 1.0.1d armhf xbian-package-tvheadend-6q/staging 1.0.1 armhf xbian-package-upstart-xbmc-bridge/stable,now 1.1.1-5 armhf [installed,automatic] xbian-package-usbmount/stable,now 1.0.5-6 all [installed] xbian-package-vnc-server/stable,staging,now 1.1.0 armhf [installed,automatic] xbian-package-webserver/stable 1.0 armhf xbian-package-x-6q/devel 1.1.1 armhf xbian-package-xbianhome/stable,now 1.0.0-4 armhf [installed] xbian-package-xbmc/staging 3.1.0-2 armhf xbian-package-xbmc-6q/staging,now 3.1.1 armhf [installed,automatic] xbian-package-xbmc-gotham-nightly/stable 3.0.1 armhf xbian-package-xbmc-gotham-nightly-6q/devel,now 3.0.1 armhf [installed] xbian-package-xbmc-scripts/stable,now 1.0.8 armhf [installed,automatic] xbian-package-xserver-xorg-video-vivante-6q/staging 1.1.1 armhf xbian-package-zram-swap/stable,now 1.0.5 armhf [installed,automatic] xbian-update/stable,now 1.0.2-97 armhf [installed]

[Iri-Dium]

Can you send the output from vmstat 5 50 when playing a video (That is "choppy") - also send link to pastebin with dmesg and xbmc.log

[321liftoff]

I think the culprit are the many lines like this in xbmc.log: "06:47:52 T:1366168336 DEBUG: CDVDPlayerAudio:: Discontinuity1 - was:720495839.407377, should be:720395028.634305, "

It's an xvid codec. Also, the audio makes everyone's voice sound deeper, which points to the audio being slower than normal. logs below:

vmstat http://pastebin.com/2gKY9qMT dmesg http://pastebin.com/fuZckYV3 xbmc.log http://pastebin.com/1pHWXPpS

[mk01]

@321liftoff

if it is PacketBitstreamed XVID then it is not wrong. unfortunate. in the first IMX6 implementation XVID's were all but nice to watch. the actual IMX6 support helped a lot, but (in my opinion) far from perfect - my knowledge is not sufficient there to comment further, but I'm sure the authors did what they could. some reading is here: https://github.com/xbmc-imx6/xbmc/pull/28

I will check XBian sources if this particular patch is included - but on 90% yes. yes, it is included. I have two samples of such XVIDs from users and I got better results playing them with SW decoding (by ffmpeg libs). there is almost no sync issues, choppiness almost none. (RPI for instance plays both samples without issues but this is because RPI is decoding it in SW too).

I posted this specific XBMC for test once to users but it is ok (because of suitable "quality" of playing) for some, and bad for other - as it take almost 1full cpu to decode. If you want to see it, I can compile such variant again for you, it's minimum work.

[mk01]

now for the audio. your XBMC is picking not the CEA 1280x720 ("S:1280x720p-60") but (U:1280x720p-60"). it is likely they have different clocks and because audio is synced to video clock, this could cause the effect o pitching up/down.

can you send me "cat /sys/class/graphics/fb0/modes" output ? in-between I look into sources to fix this can you try to force XBMC to res #19 instead of #16?

• stop xbmc, change console res with

echo "S:1280x720p-60" > /sys/class/graphics/fb0/mode

then open /home/xbian/.xbmc/userdata/guisettings.xml, and change

<resolution default="true">16</resolution>

to "19". try starting XBMC and check log if XBMC still tries "U:1280x....".

tomorrow there will be fixed xbmc at devel. let's hope it is that.

[321liftoff]

Well, I hate to report this, since it might prevent further troubleshooting, but the latest xbian updates seem to fix this issue. Below are the xbian packages that changed from my previous list:

xbian-package-firmware-6q/devel,now 1.6.0-7 armhf [installed] xbian-package-xbmc/staging 3.1.1-1 armhf xbian-package-xbmc-6q/devel,now 3.2.0-2a armhf [installed,automatic] xbian-package-xbmc-scripts/stable,now 1.0.8-1 armhf [installed,automatic] xbian-update/stable,now 1.0.2-98 armhf [installed]

Below are new logs: Dmesg http://pastebin.com/SAxAmXu5 xbmc.log http://pastebin.com/6rUVNHws

I do notice that the following line found in the "not-working log" is not found in the "working log": "06:45:35 T:1957339728 DEBUG: : SetNativeResolution - changing resolution to U:1280x720p-60"

Below is the output you requested: xbian@cubox ~ $ cat /sys/class/graphics/fb0/modes S:720x480p-60 S:720x480p-60 S:1280x720p-60 U:1280x720p-60 V:1024x768p-60 V:800x600p-60 V:640x480p-60 U:720x400p-70 D:1360x768p-59 D:1366x768p-59 V:640x480p-60

I don't think my cubox-i is using SW decoding of xvid files. In the info box when playing a video, I see the following: P(fr:23.976, vq:99%, dc:iMX-xvid, Mb/s:1.57(variable), drop:0,skip:0,pc:1) and the 4 CPUs are rarely above 12%.

Let me know if there is other info that I can provide that may help.

[mk01]

@321liftoff

all went according to plan then. only I forgot to tell you that the "fixed" package is ready to test. we wanted exactly that XBMC will not replace any CEA resolution (S:1280xxxxxx) with other type (U:) with the same resolutions and refresh. but will use it if CEAs are missing (DVI case).

but what is a bit of positive surprise to me that the extensively wrong snd clock and timing issues directly affected also video playback at such extend. thanks for this one - I'm sure you wasn't the only one victim there. but at the end should be logical as the player is of course constantly trying to re-sync video & audio. btw: this now also answers the weird opposing test results when someone reported XVID not being played ok although when I tested his media file, it was perfectly well here.

and yes the HW decoding is default and should be used - I just wanted to say before, that in case of very bad XVIDs the software decoding via ffmpeg was producing better results. but looks that this is fine now too.

feel free to report more suspicious things if you find them as the past weeks I have seen XBMC only on home screen without any real world use.

[321liftoff]

Great! I'll consider this closed.