Skip to content

Preserve fractional frame rates when encoding SDR video - #279

Open
Syed Osama Ali Shah (Osamaali313) wants to merge 1 commit into
Lightricks:mainfrom
Osamaali313:fix-fractional-fps-truncation
Open

Preserve fractional frame rates when encoding SDR video#279
Syed Osama Ali Shah (Osamaali313) wants to merge 1 commit into
Lightricks:mainfrom
Osamaali313:fix-fractional-fps-truncation

Conversation

@Osamaali313

Copy link
Copy Markdown

Summary

encode_video writes the SDR H.264 stream with a truncated integer frame rate, so fractional rates are silently wrong.

packages/ltx-pipelines/src/ltx_pipelines/utils/media_io/encode.py:

stream = container.add_stream("libx264", rate=int(fps), options={"crf": str(crf), "preset": preset})

int(fps) truncates 29.97 → 29, 23.976 → 23, 59.94 → 59. The output file is then tagged/timed at the wrong rate, so it plays ~1.6–4.2% too slow and any muxed audio drifts progressively out of sync.

This is reached on the normal path: --frame-rate is a float CLI argument (utils/args.py, "Frame rate of the generated video (fps)") and every generation pipeline (distilled, ti2vid_*, a2vid_two_stage, ic_lora, keyframe_interpolation, …) passes args.frame_rate straight to encode_video, so --frame-rate 29.97 yields a 29 fps file.

Fix

Use Fraction(fps).limit_denominator(1000) for the stream rate (widening the fps parameter to float). This matches what the codebase already does everywhere else:

  • encode_video's own HDR branch forwards fps=float(fps).
  • media_io/exr.py uses add_stream("libx264", rate=Fraction(frame_rate).limit_denominator(1000)) — the same codec — with the docstring "so playback matches the input timing."
  • ltx_core/color/hlg.py uses Fraction(fps).limit_denominator(1000) for libx265.

The SDR branch was the lone outlier. Integer rates are unchanged (Fraction(24.0).limit_denominator(1000) == 24).

I also removed the int(src.fps) pre-truncation at the retake and dubit call sites (src.fps is already a float from float(video_stream.average_rate)), so source-fps flows keep their true rate too.

Verification

Ran the real encoding path through PyAV (the same add_stream + frame-encode idiom encode_video uses):

fps input      : 29.97
RED  (int fps) : output average_rate = 29        (29.0)
GREEN(Fraction): output average_rate = 2997/100  (29.97)
24.0 fps       : output average_rate = 24         (no regression)

ruff check and ruff format are clean on the changed files.

encode_video wrote the SDR H.264 stream with rate=int(fps), truncating
fractional rates: 29.97 -> 29, 23.976 -> 23, 59.94 -> 59. The output is
then tagged/timed at the wrong rate, so the video plays a bit too slow
and muxed audio drifts out of sync over the clip. --frame-rate is a float
CLI arg and every generation pipeline passes it straight through, so a
standard broadcast rate reaches this path.

Use Fraction(fps).limit_denominator(1000) for the stream rate, matching
what encode_video's own HDR branch (float(fps)) and the sibling encoders
already do (exr.py uses the same idiom with libx264, hlg.py with libx265,
both to "match the input timing"). Integer rates are unchanged
(Fraction(24.0).limit_denominator(1000) == 24). Also stop pre-truncating
the source rate with int(src.fps) in the retake and dubit call sites so
source-fps flows keep their true rate too.
Copilot AI lite review requested due to automatic review settings August 12, 2026 20:53

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants