After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 708940 - x264enc: Never disables VFR when framerate is known
x264enc: Never disables VFR when framerate is known
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
Other All
: Normal normal
: 1.2.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2013-09-27 15:26 UTC by Michael Esemplare
Modified: 2013-10-10 10:31 UTC
See Also:
GNOME target: ---
GNOME version: ---

Patch (758 bytes, patch)
2013-09-27 15:26 UTC, Michael Esemplare
committed Details | Review

Description Michael Esemplare 2013-09-27 15:26:43 UTC
Created attachment 255945 [details] [review]

I have a video file with a fixed framerate, however the framerate is never used. My resulting encoded files always end up with VFR (0/1).

GstX264Enc sets the default x264Params with x264_param_default from libx264( which b_vfr_input is set to true:;a=blob;f=common/common.c )

I noticed that libx264 sets b_vfr_input=0 in the zerolatency profile.;a=blob;f=common/common.c#l382

Would this parameter be something that could be exposed to the plugin, such that the user can choose if they wish to use VFR.

/* VFR input.  If 1, use timebase and timestamps for ratecontrol purposes.
 * If 0, use fps only. */

The attached patch sets the b_vfr_input=false when info->fps_d/n are set.
Comment 1 Michael Esemplare 2013-09-27 15:36:46 UTC
Review of attachment 255945 [details] [review]:

Email should be <>
Comment 2 Sebastian Dröge (slomo) 2013-10-04 10:09:00 UTC
commit fc29cbaa54889876b4a556a5273f0c9ceb539c3c
Author: Michael Esemplare <>
Date:   Fri Sep 27 08:05:25 2013 -0700

    x264enc: If FPS is available, set VFR to false
Comment 3 Tim-Philipp Müller 2013-10-04 10:12:45 UTC
Note that just because the framerate is in the caps doesn't mean that you actually have a fixed framerate. Example: v4l2src. Question is if x264 expects/handles that.
Comment 4 Sebastian Dröge (slomo) 2013-10-04 10:27:59 UTC
Well, that's a good question. It will at least confuse the rate control algorithms.

But if v4l2src does not provide a fixed framerate it should not put it into the caps as framerate, but as maximum-framerate or something. The problem is that if we can't trust the framerate field at least on average, we can never produce non-vfr h264 streams.