[zfleeman]

Closes #146.

The first pass forced a constant frame rate (-fps_mode cfr) and the second pass didn't, so the two passes could see a different number of frames from the same trim (122 against 121 on 2 seconds of a 1080p60 clip). The second pass reads the first pass's stats frame by frame, so on Windows AV1's second pass crashed, and x265 logged slice=P but 2pass stats say B on every two-pass encode.

Change

TwoPass._generate_params() gives the second pass the same fps_mode_flag(self.probe): "cfr" as the first, so older ffmpeg builds get -vsync cfr on both. Hardware codecs run only the second pass, so their output is now constant frame rate too, matching the software codecs.

Checked

Windows (ffmpeg 8.1 gyan.dev essentials), 10 seconds of a 1080p60 Call of Duty clip at -s 5:

Codec	Before	After
av1	ffmpeg crashed in pass 2 (0xC0000005)	4.86 MB
x265	slice=P but 2pass stats say B in red	4.48 MB, no errors
x264	worked	4.99 MB
vp9	worked	4.93 MB
hevc_nvenc	worked	4.64 MB

On macOS, a verbose x265 encode no longer logs the B-frame warning or the slice=P error.

With the fix, AV1 retries that reuse the first pass's stats (#139, PR #145) also work: on Windows a retry from 6 to 5.1 MiB landed at 4.95 MiB, the same as a full re-encode. libaom's first pass is cheap, so the retry is only about 10% faster.

Tests

test_twopass.py: every codec's passes all use -fps_mode cfr, and an ffmpeg 4.4 probe gets -vsync cfr on both passes. The full suite passes on macOS and Windows.