KlausiMaus this effect is called color banding. What I can also see is dithering (which is a counter mechanisms against color banding).
This might be a problem of the TV or the source material, so it would be the best to check with a laptop or something if it is present there too.
Hello,
I didn't expect these builds to be prime time and nobody said they are. This is true, however they run really smooth and most things are working actually at least somehow. So kudos for these builds, looks really promising.
Setup:
Observations:
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.
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)?
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 :)).
The log doesn't tell me much. I only found this:
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.743167However 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).
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.
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
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.
That explains at least something, but now we need to find out why the Video FFU and the IOMMU crash. Are there any devices attached to the Rock64? What PSU are you using?
PS.: That download of 4K HEVC Big Buck Bunny takes forever ...
eMMC should be fine as well as any memory amount that is available for Rock64 (1GB would be sufficient too). It would be worth a try playing a file from an HDD, but I doubt that eMMC is at fault here, if it is not broken.
Are there any errors/warnings in dmesg?
I am currently on a Rock64/2GB and everything except DivX/MPEG-4 content plays fine. I never tried 4K content tho.
Hello,
I didn't find a thread about this problem, so I open one.
Setup:
Observation:
Tested:
Kind regards,
ArchNMy