[Bug] MPEG-4/DivX/Xvid videos stutter on Rock64

ArchNMy · May 7, 2019 at 2:28 PM

Hello,

I didn't find a thread about this problem, so I open one.

Setup:

Rock64
LE nightly 20190506 for Rock64 (also tested on 8.90.014)
LE installed on eMMC

Observation:

MPEG-4 (Layer 2) videos stutter
stutter is continuous throughout playback and multiple times per second (is it called jitter then?)
MPEG2/H264/H265 content plays flawlessly
resolution doesn't matter
whole kodi UI is sluggish with DivX content playing in the background (not otherwise)
video is a bit behind audio

Tested:

CPU is around 50% (from 400% possible) for the usual SD content
PRIME on/off doesn't matter (probably not accelerated anyway)
deinterlacing on/off doesn't matter (material isn't interlaced anyway)
changed framerates (also to match source framerate) and the slower it gets the worse the stutter is even if it matches the source framerate

Kind regards,

ArchNMy

flyingernst · May 10, 2019 at 12:16 PM

had the same, also with h264 and h265. Did test different SD cards (which was suggested in here) und tested different buffering settings. None of it provided a solution. No matter if I play vom SD, USB, DLNA, SMB.

I think buffering is the problem, because the grey buffering bar is jumping like a maniac, while it is very calm in other hardware/releases. Perhaps you can check that behavior on your device.

ArchNMy · May 10, 2019 at 12:21 PM

flyingernst: The stutter is more of a consistent frame drop or jitter. On 25Hz it looks like I'm watching slow motion while not really being slower. Also H264 and H265 as well as MPEG2 content plays fine for me regardless of bitrate or resolution.

LE is installed on eMMC and loads content from SMB, so it doesn't seem to be the same issue.

**Kwiboo** · May 10, 2019 at 1:29 PM

mpeg-4/xvid/divx is software decoded, try go to Video settings when playing a video and change deinterlacer to half or off.

ArchNMy · May 10, 2019 at 9:06 PM

Kwiboo: I suspected that it is software decoded, however the cpu usage doesn't exceed 70% (of 400%) so not even a single thread is completely used.

The stutter is also continuous with no apparent spikes which leads me to think it has nothing to do with CPU performance limits. Also the stutter becomes way worse when setting the display refresh rate lower (for example 24Hz/25Hz which are the source frame rates for these cases).

Deinterlacing turned off doesn't change the observed behavior.

Do you have a Rock64 and if so do you see the same behavior on MPEG4/Xvid/DivX content?

Edit: The jitter/framedrops/continuous stutter is also visible in the Kodi UI

ArchNMy · May 11, 2019 at 12:52 PM

Okay, I tested 720p H264 software decoding and it plays flawlessly while peaking at around 150% (while usually being around 110%). I think that should rule out a CPU bottleneck.

Will traverse the logs if I see anything suspicious while playing back DivX/Xvid content.

ArchNMy · May 14, 2019 at 5:44 PM

The log doesn't tell me much. I only found this:

Code

DEBUG: ActiveAE::SyncStream - average error of 16.908025, start adjusting
DEBUG: ActiveAE::SyncStream - average error 0.908025 below threshold of 30.000000
NOTICE: CDVDVideoCodecFFmpeg::CDropControl: calculated diff time: 40000
DEBUG: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:-33362.743167, adjusted:-33362.743167

However this also occurs in the smooth h264 playback test run.

Regarding the logs, I removed video location and title from the log (with place holders) and removed spam from plugin.video.youtube and service.upnext as well as jsonrpc (from Kore app).

ArchNMy · May 23, 2019 at 8:15 PM

It would even help if someone can replicate this observation on RK3328. Meaning: jittery playback on Xvid/DivX content and smooth playback on H264/AVC+H265/HEVC content

It would also help if someone has smooth playback with Xvid/DivX content on RK3328 (Rock64 preferred of course :)).

**Kwiboo** · May 23, 2019 at 8:24 PM

As I mentioned before xvid/divx/mpeg-4 is all sw decoded and will use GPU rendering instead of direct to plane rendering, please try the mainline linked to in Early mainline images for RK3288, RK3328 and RK3399

Those images will use sw decoding and direct to plane rendering, let us know if there is any difference

ArchNMy · May 23, 2019 at 8:48 PM

Kwiboo: You can't disable GPU rendering for SW decoded content? Why is SW decoded AVC content playing fine (with higher-res and higher-bitrate)?

**Kwiboo** · May 23, 2019 at 11:57 PM

No you cannot disable gpu rendering (it is the only way to render sw decoded videos). Render sw decoded video using direct to plane is still work in progress.

Possible due to a bug in Kodi, please test 8.90.015 and mainline image and see if problem is also present, they both have newer Kodi versions with important fixes.

Nightly images is using the older 18.2rc1 version with some known bugs.

LE master is still on that version because it is the latest taged version on kodi master branch.

mike2002 · May 24, 2019 at 3:17 AM

Hi !

I did a quick test with my Rock64 with Libreelec 8.90.015. I play a DivX without problem, no stutter/Jitter. I play it 5 minutes without any glitch. I previously played a lot of H264 and h265 contents without issue.

Just a little precision, my resolution is set to 720p. As soon I set it to 1080p suttering and jittering appear.

No stutter/jitter at 720p but that appear at 1080p with this video

Video

ID : 0

Format : MPEG-4 Visual

Codec ID : DIV3

Codec ID/Hint : DivX 3 Low

Duration : 1 h 57 min

Bit rate : 694 kb/s

Width : 576 pixels

Height : 432 pixels

Display aspect ratio : 4:3

Frame rate : 25.000 FPS

Color space : YUV

Chroma subsampling : 4:2:0

Bit depth : 8 bits

Compression mode : Lossy

Bits/(Pixel*Frame) : 0.112

Stream size : 585 MiB (83%)

Samething for this one :

Video

ID : 0

Format : MPEG-4 Visual

Format profile : Advanced Simple@L5

Format settings : BVOP2

Format settings, BVOP : 2

Format settings, QPel : No

Format settings, GMC : No warppoints

Format settings, Matrix : Default (MPEG)

Muxing mode : Packed bitstream

Codec ID : XVID

Codec ID/Hint : XviD

Duration : 40 min 35 s

Bit rate : 1 060 kb/s

Width : 720 pixels

Height : 404 pixels

Display aspect ratio : 16:9

Frame rate : 25.000 FPS

Color space : YUV

Chroma subsampling : 4:2:0

Bit depth : 8 bits

Scan type : Progressive

Compression mode : Lossy

Bits/(Pixel*Frame) : 0.146

Stream size : 308 MiB (88%)

Writing library : XviD 64

Personnaly I think it's more related to horsepower, I play the exact same contents in 1080p without glitch with my Rockpi4. Actually the Rock64 is clock at 1.2 Ghz, if we can clock it at 1.5 Ghz (like armbian do with the Rock64) maybe that can help to eliminate the stuttering.

**Kwiboo** · May 24, 2019 at 9:12 AM

Quote from mike2002

Just a little precision, my resolution is set to 720p. As soon I set it to 1080p suttering and jittering appear.

Good point, any scaling will be done in GPU and the GPU in rk3328 is on the lower end. Changing scale mode in OSD -> Video settings may reduce stuttering and jittering.

With the Direct-To-Plane renderer the video output processor (VOP) will do scaling and is not limited by the weaker GPU.

This is the one of the reasons I want confirmation if this issue exists using mainline images.

Quote from mike2002

Actually the Rock64 is clock at 1.2 Ghz, if we can clock it at 1.5 Ghz (like armbian do with the Rock64) maybe that can help to eliminate the stuttering.

I do not think the CPU is the limiting factor, it is the GPU. I do not remember at what freq the GPU run on RK 4.4 images, it may be limited to 500 mhz. Previous testings showed that the GPU can be run at 600mhz without issues. Mainline images will run GPU at 500mhz.

ArchNMy · May 24, 2019 at 6:02 PM

Kwiboo and mike2002: Thank you for clarification. Indeed changing resolution to 720p makes the playback of SD Xvid content smooth. I will test mainline build later on, just to see if it is there too or not.

Also because of that explanation I tested SW decoding H264 SD content and indeed this stutters as well, so the scaling is the problem.

I was really not aware that scaling is so computationally intensive. Also weird that changing to lower refresh rate really doesn't improve matters.

mike2002 · May 25, 2019 at 3:57 AM

Hi !

I did a test with the mainline build. I confirm that the problem with the Divx and the Xvid are not present (1080p). And I test a HEVC video with success, the video is smooth and the quality is really good.

mike2002 · May 26, 2019 at 3:50 AM

Hello !

after few more tests, forget this build for H265 HD but work well for H265 SD. Anyway, the future sound good for the Rock64 and other rockchips device under mainline kernel... But for the moment a lot more feature under kernel 4.4.