Pass write fps to ffmpeg as a rational (#116)

[cpruijsen]

Fixes #116

write_frames formatted ffmpeg's input -r with {:.02f}, so rates
like NTSC film (24000/1001 ≈ 23.976) were sent as -r 23.98. That
changes the file timebase (e.g. 19184 tbn instead of 24k tbn) and
can desync audio and subtitles. ffmpeg's -r already accepts a
fraction; this PR passes one.

Decision

• Chose: str(Fraction(fps).limit_denominator()) as the -r value.
• Alternative: a high-precision decimal string (str(fps)).
• Why: this is the workaround the issue author posted, and it recovers
  exact NTSC rationals from the corresponding float (24000/1001 stays
  24000/1001; integer 16 becomes 16). Happy to switch to a decimal
  if a rational on the command line is unwelcome.

Integer defaults therefore go out as -r 16 rather than -r 16.00.
Same rate for ffmpeg. input_params=['-r', ...] still overrides by
coming later on the command line.

Not in this PR: exact fps when reading. ffmpeg's banner still prints
two decimals, and this project does not ship ffprobe (the reporter
noted that; left as an acknowledged limitation).

Test plan

• test_write_fps_precision fails with the old {:.02f} (-r 23.98)
  and passes with the rational (24000/1001)
• Existing write tests still pass (default fps 16)
• CI on Linux / Windows / macOS

Fixes #116