Misc. bug: mtmd video input hangs on Windows — probe() deadlocks on faststart MP4, decode emits 0 frames when MOOV at end

[warshanks]

Name and Version

.\build\bin\Release\llama-cli.exe --version
version: 9590 (d2462f8)
built with MSVC 19.44.35227.0 for x64

Operating systems

Windows

Which llama.cpp modules do you know to be affected?

llama-cli, Other (Please specify in the next section), llama-server

Command line

.\build\bin\Release\llama-cli.exe -m gemma-4-12B-it-qat-UD-Q4_K_XL.gguf -mm mmproj-F32.gguf -v
# then in chat:
# /video C:\Users\Ben\Videos\test.mp4
# Tell me about this video

Problem description & steps to reproduce

Name and Version

version: b9590 (d2462f8)
built for Windows x86_64, CUDA backend (RTX 3090)

Operating systems

Windows

Which llama.cpp modules do you know to be affected?

llama-cli, mtmd

Problem description & steps to reproduce

Video input on Windows hangs in two different ways depending on where the MP4 MOOV atom is located. Both appear to be in the ffmpeg/ffprobe subprocess pipe handling in tools/mtmd/mtmd-helper.cpp (mtmd_helper_video). This extends #24394 (silent zero-frame failure on Linux) with Windows repro data — on Windows it hangs rather than failing silently.

Case 1: MOOV atom at end of file (default ffmpeg output)

probe() succeeds (ffprobe has to read the entire piped input to find the moov, so it fully drains stdin and exits cleanly). The ffmpeg decode step then produces zero frames:

0.24.617.771 D start_ffmpeg: launching: ffmpeg -nostdin -i cache:pipe:0 -vf fps=4.000000 -f rawvideo -pix_fmt rgb24 pipe:1 -loglevel error
0.24.622.579 D start_ffmpeg: subprocess_create ret=0 proc_alive=1
0.24.622.583 D start_ffmpeg: starting feeder thread for 1194147-byte buffer
0.24.622.649 D read_next_frame: reading frame 0, expecting 2764800 bytes (720x1280)
0.24.668.259 D read_next_frame: fread returned 0 after 0/2764800 bytes (ferror=0)
0.24.668.268 D add_text: <|turn>system ...
0.24.668.306 D add_text: Video:
0.24.668.319 D add_text: Tell me about this video<turn|>

The prompt is assembled with the bare Video: text and no frames, and then llama-cli hangs (no generation, no error).

Case 2: MOOV atom at front (-movflags +faststart)

After remuxing the same file with ffmpeg -i test.mp4 -c copy -movflags +faststart test_fast.mp4, the hang moves earlier, into probe() itself. The log stops here and never prints the probe result line:

0.28.766.262 D res  add_waiting_: add task 0 to waiting list. current waiting = 0 (before add)
0.28.766.269 D que    post: new task, id = 0, front = 0
0.28.767.532 D probe: launching: ffprobe -v quiet -show_entries stream=width,height,r_frame_rate,nb_frames,duration -select_streams v:0 -of default=noprint_wrappers=1 pipe:0
(hangs indefinitely)

Isolation: ffprobe itself behaves correctly on the same file

Running the exact probe command manually with a real pipe (cmd.exe, binary-safe):

C:\Users\Ben>cmd /c "type C:\Users\Ben\Videos\test_fast.mp4 | ffprobe -v quiet -show_entries stream=width,height,r_frame_rate,nb_frames,duration -select_streams v:0 -of default=noprint_wrappers=1 pipe:0"
width=720
height=1280
r_frame_rate=30/1
duration=7.050391
nb_frames=211
The process tried to write to a nonexistent pipe.

ffprobe prints the metadata and exits promptly. Because the moov is at the front, it stops reading stdin early; the writer (type) gets the expected broken-pipe error and terminates. So the deadlock is in how mtmd_helper_video handles this early-exit case on Windows: the feeder thread is blocked in fwrite() on the child's stdin while the main thread is blocked in fgets() on the child's stdout, and neither unblocks when ffprobe stops reading / exits.

Minor side issue while debugging: the probe() debug line prints fps_target and a not-yet-assigned info.n_frames, e.g. probe: 720x1280 fps=4.00 duration=7.02s n_frames=0 for a 30 fps / 211-frame video — info.n_frames is assigned on the line after the LOG_DBG, and fps here is the sampling target, not the source fps. Made the logs confusing to interpret.

Test video: 720x1280, H.264, 7.05 s, 30 fps, ~1.2 MB. Happy to provide the file or more verbose logs if useful.

First Bad Commit

Video input is new in #24269 (b9577); also reproduces after the #24316 refactor.

Relevant log output

Logs

[warshanks]

I troubleshot with Fable and found the root cause to be subprocess.h on Windows keeping the read end of the child's stdin pipe open after spawn, so when ffprobe/ffmpeg exits without draining stdin, the feeder thread's write never gets a broken pipe and feeder.join() deadlocks.
The alternate fix is close startInfo.hStdInput after CreateProcess in vendored subprocess.h, like it already does for stdout/stderr

The patch I'm using is here if it's any help: https://github.com/warshanks/llama.cpp/tree/mtmd-video-win-deadlock

[bingoct]

still in
llama-server --version
version: 9828 (ebd048f)
built with Clang 20.1.8 for Windows x86_64

4.21.963.360 D probe: launching:4.21.963.367 D  ffprobe4.21.963.367 D  -v4.21.963.367 D  quiet4.21.963.368 D  -show_entries4.21.963.368 D  stream=width,height,r_frame_rate,nb_frames,duration4.21.963.368 D  -select_streams4.21.963.369 D  v:04.21.963.369 D  -of4.21.963.369 D  default=noprint_wrappers=14.21.963.370 D  pipe:04.21.963.370 D
4.22.010.096 D probe: 1280x720 fps=4.00 duration=157.00s n_frames=0
4.22.010.564 D start_ffmpeg: launching:4.22.010.570 D  ffmpeg4.22.010.571 D  -nostdin4.22.010.571 D  -i4.22.010.571 D  cache:pipe:04.22.010.572 D  -vf4.22.010.572 D  fps=4.0000004.22.010.572 D  -f4.22.010.573 D
rawvideo4.22.010.573 D  -pix_fmt4.22.010.573 D  rgb244.22.010.574 D  pipe:14.22.010.574 D  -loglevel4.22.010.574 D  error4.22.010.575 D
4.22.014.633 D start_ffmpeg: subprocess_create ret=0 proc_alive=1
4.22.014.638 D start_ffmpeg: starting feeder thread for 5640856-byte buffer
4.22.014.684 D expand_lazy_bitmaps: expanding lazy bitmap
4.22.014.685 D read_next: proc_alive=1 start_emitted=0 current_frame=0
4.22.014.689 D expand_lazy_bitmaps: lazy callback returned text: Video:
4.22.014.690 D read_next: proc_alive=1 start_emitted=1 current_frame=0
4.22.014.691 D read_next_frame: reading frame 0, expecting 2764800 bytes (1280x720)
4.22.055.036 D read_next_frame: fread returned 0 after 0/2764800 bytes (ferror=0)

[githubsean]

I get the same issue.

0.15.360.087 D que    start_loop: waiting for new tasks
4.56.632.190 I srv  server_strea: conv_id=82963e38-6e99-434e-97af-828f444eed56 (empty=0)
4.56.648.923 D probe: launching:4.56.648.928 D  ffprobe4.56.648.928 D  -v4.56.648.929 D  quiet4.56.648.929 D  -show_entries4.56.648.929 D  stream=width,height,r_frame_rate,nb_frames,duration4.56.648.930 D  -select_streams4.56.648.930 D  v:04.56.648.931 D  -of4.56.648.931 D  default=noprint_wrappers=14.56.648.931 D  pipe:04.56.648.932 D

If I add in some missing newlines

0.15.360.087 D que    start_loop: waiting for new tasks
4.56.632.190 I srv  server_strea: conv_id=82963e38-6e99-434e-97af-828f444eed56 (empty=0)
4.56.648.923 D probe: launching:
4.56.648.928 D  ffprobe
4.56.648.928 D  -v
4.56.648.929 D  quiet
4.56.648.929 D  -show_entries
4.56.648.929 D  stream=width,height,r_frame_rate,nb_frames,duration
4.56.648.930 D  -select_streams
4.56.648.930 D  v:0
4.56.648.931 D  -of
4.56.648.931 D  default=noprint_wrappers=1
4.56.648.931 D  pipe:0
4.56.648.932 D

Running the command directly works:

ffprobe -v quiet -show_entries stream=width,height,r_frame_rate,nb_frames,duration -select_streams v:0 -of default=noprint_wrappers=1 pipe:0 < "WhatsApp Video 2026-07-20 at 18.06.16.mp4"
width=848
height=480
r_frame_rate=600/19
duration=84.201667
nb_frames=2525

Some version information (downloaded ~ 2026-07-20T08:00:00Z)

llama-server --version
version: 10069 (178a6c449)
built with Clang 20.1.8 for Windows x86_64