[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