Fix single-threaded decode hang when ready_tasks is zero - #25
Open
intrepidsilence wants to merge 1 commit into
Open
Fix single-threaded decode hang when ready_tasks is zero#25intrepidsilence wants to merge 1 commit into
intrepidsilence wants to merge 1 commit into
Conversation
In single-threaded mode (n_threads == 0), after initializing a task, the code directly calls worker_loop. However, ready_tasks can be zero at this point because the dependency calculation at line 1256 may not account for the current frame being in a transitional state during single-threaded execution. In multithreaded mode, worker threads recalculate ready_tasks after completing each task (line 572), providing a second chance. In single-threaded mode there is no such recalculation, so the task is never executed and the decoder hangs. Add a safety net that force-sets the task bit when ready_tasks is unexpectedly zero in single-threaded mode, allowing the worker loop to proceed. Symptom: decoder hangs indefinitely with 0% CPU on certain MVC streams. Verified on commercial 3D Blu-ray content.
jens-duttke
referenced
this pull request
in jens-duttke/edge264-mvc
Jun 25, 2026
The "What's fixed vs upstream master" table only listed the MVC-correctness patches. Group it and add every fix that had since landed - the sample-audit decode-robustness sweep and the MinGW / wasm build fixes. Describe each robustness fix by its generic failure mode; keep private sample filenames, frame counts and volatile source line numbers out of this public doc. Move the single-threaded decode hang (PR #25) out of the MVC table - it is a general single-thread fix, not MVC-specific - into the single-thread lead note. Remove the now-redundant Status section, keeping only its non-redundant facts (single-thread requirement, +4 POC API fields, upstream-match result, and a "Deliberately not included" note for PR #26 and unsupported NAL types).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
In single-threaded mode (
n_threads == 0), after initializing a task,ready_taskscan be zero because the dependency calculation may not account for the current frame being in a transitional state. The code then callsworker_loopdirectly, but no task is selected becauseready_tasksis empty, causing the decoder to hang.In multithreaded mode, worker threads recalculate
ready_tasksafter completing each task (line ~572), providing a second chance. In single-threaded mode there is no such recalculation.Fix
Add a safety net that force-sets the task bit when
ready_tasksis unexpectedly zero in single-threaded mode:Symptom
Decoder hangs indefinitely with 0% CPU on certain MVC streams. The task is initialized but never executed.
Verification