Im guessing there is gonna be no fix for this, something wrong with the .ko file? it seems only on FEL files not MEL
edit: tested film with MEL and got the same drifting issues
edit: played it again with DV disabled, drifting issues gone
Is it possible there will be a fix in the future for the stuttering that occurs during the last few seconds of AV1 and VP9 videos? It’s even worse on YouTube addon. I know this might not be a priority for you, but it’s not about wanting to watch the black screen after the final end credits. There are shorter videos—even just 30 seconds long—that aren’t movies and don’t have end credits. I even have a comparison video showing this, though I realize no one will likely be interested. However, I can provide a debug log if you aren’t experiencing the issue yourselves.
Btw thank you for your hard work doing this developement
…
With SW decoding everything is perfect
Any PR is welcome.
https://paste.coreelec.org/BowieKinder
Does anyone see anything useful in this?
I don’t know how to open a public request on GitHub, I’m not an expert at this, so I’ll write it here instead.
Video playback using the hardware decoder repeatedly stalls for ~250–1200ms shortly before the end of a file, causing a visible freeze/hiccup a second or so before playback finishes. This happens across multiple codecs (AV1, H.264, VP9), so it does not look codec-specific.
Switching the same content to software decoding does not reproduce the stall.
SW decoding log.
https://paste.coreelec.org/SlamsSouls
20260730
Factory reseted system. No addon installed, no extra settings. My other box also produces this error (S905X3 generic) with an other SD card.
The May 4th release behaves a little differently. At the end of the video, there is no stutter or hiccup, but the image freezes for a moment. This is a slightly better solution if you have to choose between two bad things.
I haven’t tested which version changed the situation after May 4th, because you didn’t consider my report important.
Claude AI help
Observed behavior
(all four files forced through Amlogic HW decode, incl. the 4K AV1 clip)
Clear stalls reproduced in 3 of 4 files, consistently clustered in the last ~1–2 seconds of each file’s timeline:
AV1 4K HDR 24fps Jolt clip.mkv (duration 24.672s) — stalls at pts 22.87–23.87s (last ~1.8s):
CAMLCodec::GetPicture: index: 2837, pts: 22.871, dur:42.000ms elf:238ms
CAMLCodec::GetPicture: index: 2839, pts: 22.954, dur:41.000ms elf:421ms
CAMLCodec::GetPicture: index: 2845, pts: 23.204, dur:41.000ms elf:417ms
CAMLCodec::GetPicture: index: 2853, pts: 23.538, dur:42.000ms elf:417ms
CAMLCodec::GetPicture: index: 2861, pts: 23.871, dur:42.000ms elf:417ms
(There is also a very large one-off 1169ms elf spike right at the start of this run, at pts 1.454s, with the video output queue ~10s behind the already-decoded dav1d/demux position — possibly a separate startup-buffering issue, noted here for completeness but not the main focus of this report.)
av1.webm (duration 67.201s) — stalls at three points, most severe right before EOF (pts 66.07–66.73s):
CAMLCodec::GetPicture: index: 3054, pts: 53.367, dur:33.344ms elf:274ms
CAMLCodec::GetPicture: index: 3435, pts: 66.067, dur:33.999ms elf:354ms
CAMLCodec::GetPicture: index: 3446, pts: 66.433, dur:33.000ms elf:334ms
CAMLCodec::GetPicture: index: 3455, pts: 66.733, dur:33.000ms elf:334ms
vp9.webm (duration 67.201s) — stalls at pts 66.27–66.63s, immediately followed by an audio underrun right at EOF:
CAMLCodec::GetPicture: index: 4644, pts: 66.266, dur:33.000ms elf:334ms
CAMLCodec::GetPicture: index: 4650, pts: 66.466, dur:32.999ms elf:334ms
CVideoPlayerAudio::Process - stream stalled
CAMLCodec::GetPicture: index: 4655, pts: 66.633, dur:33.000ms elf:334ms
h264.mp4 did not show a comparable near-EOF spike in this particular run (only one small 225ms spike at the very start), so the issue does not reproduce 100% of the time on every file/run — but it reproduced consistently for VP9 and AV1 content across two separate full logs collected on different days.
Run 3 — control run, all four files forced through pure software decoding
To isolate the HW decode path as the cause, all four files were replayed a third time with hardware decoding disabled, so every file went through CDVDVideoCodecFFmpeg (dav1d for AV1, ffmpeg’s built-in VP9 decoder, ffmpeg’s built-in H.264 decoder — zero CAMLCodec/Amlogic calls anywhere in this run):
CDVDVideoCodecFFmpeg::Open() Using codec: dav1d AV1 decoder by VideoLAN
CDVDVideoCodecFFmpeg::Open() Using codec: Google VP9
CDVDVideoCodecFFmpeg::Open() Using codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
Result: zero elf spikes above the ~40ms baseline across all four files, including the two (AV1 4K clip, VP9) that reliably stuttered under HW decode in Runs 1–2. The only log line of note is the same single CVideoPlayerAudio::Process - stream stalled at EOF for the AV1 4K clip that also appeared in the HW runs — but this time with no accompanying video freeze, confirming it’s a harmless audio-buffer-drain marker at EOF, not the cause of the visible stutter.
This is a clean before/after control: identical files, identical device, only the decode path changed (Amlogic HW vs. FFmpeg SW), and the stutter disappears entirely with SW decoding.
Why this looks like a HW-decoder-path issue, not a codec or I/O issue
- Reproduces across three unrelated codecs (AV1, H.264 in an earlier log, VP9) that share only the Amlogic HW decode path (
CAMLCodec/DVDVideoCodecAmlogic). - Does not reproduce for the same 4K AV1 clip when it used the software
dav1ddecoder (CDVDVideoCodecFFmpeg) in Run 1, and does not reproduce for any of the four files when all of them are forced through pure software decoding in Run 3 (see control run below). - The stalls consistently cluster in the last 1–2 seconds of each clip’s timeline (near EOS), suggesting an end-of-stream/flush handling quirk in the Amlogic decoder driver rather than a general streaming/cache problem.
- Reproducibility seems to increase on a second consecutive HW-decode pass within the same Kodi session (Run 2 had many more/worse spikes than Run 1 for the same files), which may point to decoder/buffer state not being fully reset between opens.
Samples
4K AV1 Jolt clip
https://mega.nz/file/GShnVJxS#PQWSfOsd5L3nMq1WBIRkvnKDW8uYRGibDjK9UFzwNrI
AV1
https://mega.nz/file/Ig82HTzR#9kqYqdKmHO7fMsn-VEUy26FUu93-ddbhobEz2XcA2hk
H264
https://mega.nz/file/BkkRXToY#-a5wgp2ljM41bh-pw6aOLcqTEh56LX9rmOJj1BjUSQE
VP9
https://mega.nz/file/059jQKAQ#AVYbPCYn5QcbuyOhKRQ0a_6QMb67FFvrDaEtqO_Q6-s
I dont see this (Tox3 905x4) 20260730
Maybe others dont either?
Device: Ugoos AM8 Pro
SoC: Amlogic S928X
RAM: 8 GB
Boot medium: microSD
CoreELEC versions tested:
22 Alpha 1
22 Alpha 2
22 Alpha 3
22 Beta 1
DTB: stock am8 DTB supplied with each respective release
Kodi: bundled with CoreELEC
Playback:
Native Jellyfin integration
Media stored on NFS mount (kernel-level mount)
Display:
1080p projector
SDR only
No HDR
No Dolby Vision
Problem
During hardware video playback, contiguous CMA memory gradually decreases until Kodi crashes and the system reboots.
Typical failure sequence:
Video plays normally.
Audio begins looping the last buffer.
Screen turns black.
Kodi crashes.
Device reboots (watchdog).
The problem only occurs during video playback.
System is stable indefinitely when:
idle (tested for 5 days)
playing music
browsing the UI
CMA observations
Initial:
CmaFree ≈ 1985 MB
During failing playback:
44 min: CmaFree ≈ 1141 MB
51 min: CmaFree ≈ 792 MB
58 min: CmaFree ≈ 410 MB
(examble on Sherlock Holmes 2009)
After stopping playback:
CmaFree recovers only partially (approximately 670 MB), never returning to the initial value.
Starting another video after this can causes an immediate crash if little of memory was left.
Normal system RAM does not show a comparable increase.
Debugging performed
Fresh SD card formatted before every installation
No restored userdata
Multiple CoreELEC versions tested
Different Arctic and stock estuary skins tested
Debug logging enabled
CMA monitored through:
grep -i Cma /proc/meminfo
DMA-BUF inspection:
cat /sys/kernel/debug/dma_buf/bufinfo
Result remains constant:
3 DMA-BUF objects
~87 MB total
No increasing exported DMA-BUF count was observed.
Kernel log before reboot contains only repeated:
dim:warn:irq:flag 0
No GPU fault, kernel panic, or OOM messages appear before SSH connection is lost.
Codec testing
Initially AV1 appeared stable, but further testing showed codec alone is not the determining factor.
Failing file
Alice in Wonderland
MKV
AV1 Main
1920×1080
10-bit
23.976 fps
AV1 codec string: av01.0.08M.10.0.111.01.01.01.0
Video bitrate: ~8.18 Mb/s
DTS-HD MA + DTS + AC3
2 PGS subtitle tracks
Result:
Rapid CMA depletion
Crash after approximately 20 minutes
Working file
Project Hail Mary
MKV
AV1 Main
1920×1080
10-bit
24 fps
AV1 codec string: av01.0.08M.10.0.110.01.01.01.0
Video bitrate: ~0.77 Mb/s
HE-AAC stereo
35 SRT subtitle tracks
Result:
Over 2 hours playback
No measurable CMA leak
Additional testing
Disabling subtitles does not resolve the issue.
Hard factory reset, stock skin, file played from usb flash drive, movie stripped from everything except video track - no subtitles, audio, tags, chapters etc - leak stills occurred but slower
FFmpeg software decoding reports no bitstream corruption.
Audio playback alone never reproduces the problem.
System idle for multiple days remains stable.
Additional information
Im not an IT person report above is an export from AI chat after 3 days of trouble shooting and hitting the wall time and time again - if any additional information is necessary, please word it in a way layman can understand.
Approximately 80% (if not more) of my movie library of hundreds of movies are causing problems both files ripped from BD and transcoded by me as well as privatized from internet h264, h265, av1 all cause problems - tho movies and tv series with low bit-rate are in general less problematic than high quality rips
older logs as i just wiped installation to try again with clean sheet and all logs perished but the SIGSEGV is consistent with current crashes - the Crash in FT_Done_Face / FreeType was resolved by overwriting subtitles styles
I had the same problem with Odroid N2+ , never posted as i really could not stay anymore on 22 Alpha and nightlies (only one system in my living room) - I have switched back to stable CE21 and its again perfect - no memory leak whatsoever
Edit: To clarify, used memory kept rising, even when playing small files When reaching aprox 75-80% the N2 would crash. I never did any testing, i thought someone else would report it soon…. or its just me…
Well glad im not the only one, in that case maybe the problem will be escalated higher up and finally receive fix
Interesting that odin have s922x but am8 pro have s928x and they both have the same problem.
good to know that 21 do not have that problem i was trying to go never and never in hopes of finding fix alpha 1, 2, 3, beta, nighties but all have the same problem…