v0.3.17 - the empty recording was an odd width, and my earlier answer was wrong

v0.3.17

Sensitive to flashing images? See the note in v0.3.13 - it still applies.

Record: the empty file is fixed

A 924-byte .mp4 with no frames in it, reported twice. The cause was in the log all along, in two lines:

[record] video codec: hevc_amf
[record] encoding aborted: [Errno 1313558101] Unknown error occurred: 'avcodec_send_frame()'

1313558101 is 0x4E4B4E55 - the ASCII bytes "UNKN". That is AMF's AMF_UNKNOWN: a bare refusal with no cause attached, on the FIRST frame.

The cause is the frame size. yuv420p subsamples chroma 2x2, so BOTH dimensions must be even - an odd width has no chroma column to sit on. This code already knew about the height and said nothing about the width, and a borderless window measures 1059 px in windowed mode. In the reporter's own run the window was 1059x720: the height was fine and only the width was wrong.

Why it never showed up here: NVENC tolerates the odd width. AMF does not. The whole fault was invisible on an NVIDIA machine by construction.

Both dimensions are now made even before the codec is opened, and a frame that arrives one pixel larger is cropped to match - handing an encoder a frame of a size other than its own is the same refusal by another route.

One thing this fix cannot be proven by on this bench, stated rather than implied: removing the crop does not fail the live test, because NVENC accepts it. The crop is defensive - it makes the frame match the declared stream exactly, which is what AMF is entitled to require - and it is guarded by the source-level check instead. That is recorded in the test file itself.

Correction

In issue #1 I said recording needs the pixels back on the CPU every frame, and that is wrong. The log from that reporter's own run shows the button working, the encoder being chosen, recording starting, and the result pixels arriving through shared memory - 14 MB a frame. It failed at the encoder, on a size. The recording path was never missing frames; it was handed a frame the codec would not take.

Still open

Flicker on a Radeon (3.33 Hz, one presented frame per state). Not fixed, not claimed. The instrument is a run with NS_AMD_PROBE_EACH=1, which has not been done yet.

The menu in a button-taken windowed screenshot - reported again on v0.3.15, so my earlier placement fix did not settle it.

The D3D12Core fault on the RX 7600 / Windows 10 machine. v0.3.16 added the A/B arm to test it with; the answer needs that reporter's log.

Suite: 164 checks, all green, on an RTX 5070 Ti. Nothing here was run on a Radeon. The new checks fail on the odd-width version of the recorder.