You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(helper): widen NVDEC pool to 32 + retry truncated video via software
NVENC's NVDEC reference-pool starvation surfaces a second failure mode
beyond the cold-start one the seg-0 software-decode path already
handles: at certain content offsets inside HEVC sources (Tubi catalog
at the 16-24 s mark in observed sessions), the decoder runs out of
reference frames mid-segment and the encoder drops most video frames.
The TS file passes the sync-byte gate and the PES-presence gate
because PAT/PMT and audio land normally, but ffprobe reports the
video stream as 0.7-1.0 s of duration against a 4 s window. The
player either freezes when the video stream ends or desyncs audio.
Two changes:
1. Bump -extra_hw_frames from 16 to 32 on the NVENC backend. 16 was a
first guess and works for shallow reference chains but Tubi content
at certain time offsets needs more. 32 covers the deepest chains
observed in the wild without meaningfully growing GPU memory
(each surface is ~1 MB at 480p; the total pool is bounded).
2. Post-encode video-duration check in HelperLeaseWorker.RunAsync.
After ValidateMpegTs passes, on the hardware path only, run
ProbeVideoDurationAsync against the output and compare to the
lease's expected duration. If the video stream came back at < 80 %
of expected, retry the encode via BuildSegmentCommandSoftwareFallback
(the same path seg 0 uses) before uploading. Catches the truncated
output locally so a known-bad segment never reaches the server.
0 commit comments