GNOME Bugzilla – Bug 708940
x264enc: Never disables VFR when framerate is known
Last modified: 2013-10-10 10:31:47 UTC
Created attachment 255945 [details] [review] Patch 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: http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=common/common.c ) I noticed that libx264 sets b_vfr_input=0 in the zerolatency profile. http://git.videolan.org/gitweb.cgi?p=x264.git;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.
Review of attachment 255945 [details] [review]: Email should be <michael.esemplare@gmail.com>
commit fc29cbaa54889876b4a556a5273f0c9ceb539c3c Author: Michael Esemplare <michael.esemplare@gmail.com> Date: Fri Sep 27 08:05:25 2013 -0700 x264enc: If FPS is available, set VFR to false https://bugzilla.gnome.org/show_bug.cgi?id=708940
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.
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.