Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Crash: avformat decoder cache (size 4) evicts state another thread is still decoding with

Open
  • Is something wrong?
#1,318 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@iDoMeteor is already working on this.

Since Oct 1, 2026.

  • #1330 by @iDoMeteor — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c
Domain
audio-video-rtc, backend

Research direction

Start with the producer_avformat producer_get_frame path and the mlt_service_cache_put() and mlt_service_cache_set_size() entry points. Run the linked cachelimit.c reproduction with multiple threads, then trace when cached decoder state is evicted and closed. Done means concurrent producers no longer use freed state without requiring the caller to raise the cache size.

Written by the indexing model from the issue text.

Description

Environment: MLT 7.40.0 (Fedora 44 package, x86_64), FFmpeg 8.1.2. The code involved is unchanged on master (0926a75).

Found while building a GTK4 video editor on MLT; the repro below uses only melt/libmlt.

What happens

producer_avformat keeps its decoder state in the service cache "producer_avformat", whose default size is 4 process-wide (mlt_service_cache_put()). When a fifth producer decodes, the least recently used entry is evicted and its state closed, even if another thread is decoding with it at that moment. So more than four producers decoding concurrently on different threads crash.

Repro

Sixteen threads, each with its own avformat producer of the same clip (all opened on the main thread first, so the lazy-init races can't hit), read 150 frames of video and audio (C, 60 lines): https://github.com/iDoMeteor/u-studio-video-editor/tree/70841c3/tools/upstream-repros/mlt/avformat-cache-limit

ffmpeg -f lavfi -i testsrc2=s=640x360:r=25:d=8 -f lavfi -i sine=d=8 \
    -c:v libx264 -g 25 -pix_fmt yuv420p -c:a aac clip.mp4
cc -g cachelimit.c -o cachelimit -pthread $(pkg-config --cflags --libs mlt-framework-7)
for i in $(seq 30); do ./cachelimit clip.mp4 || echo crash; done | grep -c crash        # 30
for i in $(seq 30); do ./cachelimit clip.mp4 raise || echo crash; done | grep -c crash  # 0

Every crash is in __pthread_mutex_lock ← mlt_properties_get ← producer_get_frame (avformat) ← mlt_service_get_frame. raise calls mlt_service_cache_set_size(…, "producer_avformat", 17) first: 0 of 30. With 8 threads the rate varies with load (2 to 13 of 30 here).

Expected: concurrent decoding on separate producers is safe, or at worst slower. Actual: use of freed decoder state.

Notes

Either an entry in use should survive eviction until its user is done with it, or the limit should be documented as having to cover every concurrent decoder. kdenlive raises the size for the same reason; we set it to threads + 2 per track.

Dominant language
C
Stars
1.9k
Forks
391
Avg merge
1d 17h
Merged PRs (30d)
12

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from mltframework/mlt

All issues in mltframework/mlt

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.