[x264-devel] [RFC PATCH 0/1] encoder: decouple VUI timing signaling from RC/HRD timebase

Alex Konovalov alexcon314 at gmail.com
Fri Jul 10 12:29:51 UTC 2026


From: alexcon <a.konovalov at erlyvideo.org>

Hi,

I'm carrying this downstream in FFmpeg+x264 setups and would like feedback
before proposing it as a non-RFC patch.

This patch is based on x264 commit
4613ac3c15fd75cebc4b9f65b7fb95e70a3acce1.

In pipelines where nominal FPS and encoder timebase diverge, x264 currently
derives SPS/VUI timing from timebase and also uses the same timing scale in
RC/HRD paths. In practice this can lead to inconsistent timing signaling
(e.g. SPS-derived r_frame_rate becoming unrealistic in mismatch scenarios).

Minimal repro (unpatched vs patched on same source):

1) Generate source:
ffmpeg -hide_banner -nostats -loglevel error -y \
  -f lavfi -i testsrc2=size=1280x720:rate=25 -t 2 -pix_fmt yuv420p /tmp/repro-src.y4m

2) Create timecode file:
python3 - <<'PY'
with open('/tmp/repro.tc','w') as f:
    f.write('# timecode format v2\n')
    for i in range(50):
        f.write(f'{i*40}\n')
PY

3) Encode with x264:
x264 --input-csp i420 --input-res 1280x720 \
  --timebase 1/90000 --tcfile-in /tmp/repro.tc --frames 50 \
  --vbv-maxrate 1000 --vbv-bufsize 1000 --nal-hrd vbr --bitrate 1000 \
  -o /tmp/out.264 /tmp/repro-src.y4m

4) Inspect SPS timing:
ffmpeg -hide_banner -i /tmp/out.264 -c copy -bsf:v trace_headers -f null - 2> /tmp/trace.log
rg "num_units_in_tick|time_scale|fixed_frame_rate_flag" /tmp/trace.log

Observed on my side:
- unpatched: num_units_in_tick=1, time_scale=180000
- patched: num_units_in_tick=1, time_scale=50

5) Inspect SPS timing with ffprobe:
/usr/bin/ffprobe -v error -show_streams /tmp/out.264 | rg "r_frame_rate|avg_frame_rate"

ffprobe also differs accordingly:
- unpatched: r_frame_rate=180000/1, avg_frame_rate=25/1
- patched: r_frame_rate=50/1, avg_frame_rate=25/1

This patch separates the two roles:
- VUI timing signaling is derived from fps (i_fps_num/i_fps_den)
- internal RC/HRD timing math is derived from encoder timebase
  (i_timebase_num/i_timebase_den)

I used x265 behavior as a reference point for expected separation of
signaling vs internal timing model. APIs differ, but the intent is similar.

If useful, I can send v2 with any requested adjustments.

Thanks.

alexcon (1):
  encoder: decouple VUI timing signaling from internal RC/HRD timebase

 encoder/ratecontrol.c | 38 +++++++++++++++++++-------------------
 encoder/set.c         |  6 +++---
 encoder/slicetype.c   | 14 +++++++-------
 3 files changed, 29 insertions(+), 29 deletions(-)

-- 
2.47.3



More information about the x264-devel mailing list