MVX empty-capture candidate trace audit

This audit covers the physical board traces in mvx-patched-traces.tar.gz, SHA-256 7c8c6558a8bce911d9660d2afea92b64ce416d80f6340ea305ca7b1ce9558775 (243864 bytes). The archive contains three capped runs, one uncapped EOF run, and the coordinator’s exit-status record. It is evidence for the local FFmpeg candidate only; it does not enable the patch in the image or make it an mpv default.

Provenance

The logs identify FFmpeg 9.0.1 using h264_v4l2m2m on MVX /dev/video0, with H.264 input /run/bbb-360p-sample.mp4 (640x360, 30 fps), a null output, and FFmpeg decoder/filter/encoder timestamp logging. MVX_IOCTL_TRACE records the V4L2 queue boundary. The candidate is the local source patch nix/patches/ffmpeg-v4l2-requeue-empty-capture.patch: it requeues only zero-payload, non-draining, non-LAST capture dequeues. The exact shell invocation is not preserved separately; the raw FFmpeg configuration and observed arguments are retained in each archive member, so this record does not reconstruct omitted arguments.

Completion and empty-capture result

mvx-candidate-result.txt records exit status zero for all four runs. Each capped run muxed 300 frames over 10.00 seconds, with elapsed times 1.48, 1.45, and 1.47 seconds. The uncapped run muxed and decoded 480 frames over 16.00 seconds in 2.10 seconds, reported zero decode errors, and reached decoder and filter EOF.

Every trace has exactly 20 intact initial CAPTURE_MPLANE DQBUF lines with bytesused=0, timestamp zero and flags 0x00004001. Each has one intact decoder, filter, and encoder PTS-zero line, consistent with the empty buffers being requeued instead of becoming twenty zero-PTS frames. This is not a per-buffer event-ID proof because FFmpeg and tracer writes share stderr. In the EOF run the final nonempty capture dequeue has bytesused=230400 and flags 0x10104001; normal EOF completed. Thus the trace is consistent with the candidate retaining the nonempty and end-of-stream path.

Remaining timestamp defect

The candidate does not repair the capture timestamp association. Each capped run has an intact duplicate capture dequeue timestamp 7.933333; decoder, filter, and encoder each show PTS 238 twice and no PTS 239. The EOF run repeats that defect and adds three intact capture dequeues with timestamp 12.033333. Its decoder/filter/encoder records show PTS 361 three times and omit 362 and 363. The upstream demuxer records the input PTS 239, so this is not evidence of a missing input packet. It locates the remaining failure at or below the MVX capture boundary, then shows FFmpeg preserving it.

The capped filter and encoder logs each contain 300 frame records but only 299 unique PTS values because of the 238/239 duplicate/gap. The EOF filter and encoder logs each contain 480 records but only 477 unique values (duplicate 238, triple 361, missing 239/362/363). Decoder literal-line counts differ from the stream summaries because the capped decode thread runs beyond the output frame limit and concurrent stderr lines interleave; they do not prove a frame loss. Similarly, only intact trace-prefix records can be counted exactly. The archive is retained so later work can parse or instrument a serialized boundary without treating these logging artifacts as a packet-to-frame proof.

Decision

The narrow requeue behavior and successful EOF repeat support using this patch only as a local diagnostic override for the next mpv native-PTS trial. Do not enable it globally or claim timestamp correctness. A follow-up must preserve the trace and investigate the duplicated MVX capture timestamps before making playback timing policy depend on this candidate.