libx264 does not yet support the features that create the difference
between baseline and constrained baseline profile. Hence it currently
supports both though it can only technically encode constrained
baseline.
Read the stream-format from "stream-format" and not from profile, also rename
the "bytestream" variable to "stream_format" so it's easier to understand.
Makes x264 select its stream-format based on what's available
on caps, the user selected option will be chosen as a fallback
when both options are available.
https://bugzilla.gnome.org/show_bug.cgi?id=644233
Although the element accepts subme values > 6, the annotation which is
visible through gst-inspect (for example) erroneously indicates 6 as the
maximum. Fix this by indicating 10 (which is the x264 max) as the maximum.
https://bugzilla.gnome.org/show_bug.cgi?id=653473
When variable framerate is disabled in libx264 (which occurs when using
the zerolatency tuning), libx264 ignores timestamps but still uses the
timebase leading to messed up rate control with our nanosecond timebase.
We work around this issue by setting the timebase to the reciprocal of
the framerate and we validate that the framerate is suitable.
This has been fixed upstream in libx264 but there are non-fixed versions
in the wild so this workaround is still needed.
Fixes bug #632861
In X264_BUILD >= 78, b-pyramid became a non-boolean so passing a boolean
argument to the option string value causes an error. For < 78 we pass the
boolean value, for >= 78 we use the x264_b_pyramid_names[] array which will
result in passing 'none' for false and 'strict' for true. Other modes can be
set through the option-string property for now.
https://bugzilla.gnome.org/show_bug.cgi?id=626577
x264_encoder_encode() should be called with a NULL picture until at least
x264_encoder_delayed_frames() returns 0. This fixes what appeared to be a
regression in make check due to the recent change in defaults which enabled
b-frames and b-pyramid, both of which I believe increase the number of delayed
frames when encoding.
Use of a rate control method (pass, bitrate, quantizer, etc properties), a
preset and possibly a profile and/or tuning are now the recommended way to
configure x264 through x264enc.
If a preset/tuning are specified then these will define the default values and
the property defaults will be ignored. After this the option-string property is
applied, followed by the user-set properties, fast first pass restrictions and
finally the profile restrictions.
Addresses part of bug #607798
- Make defaults append the appropriate default value to a string. This is
needed to differentiate between something user-set and the actual prop
default.
- Add an internal option string to which _set_property () cases append for the
majority of properties.
- Use gst_x264_enc_parse_options () to clean up application of settings. This
will make order of application with respect to the presets and tunings quite
simple.
Addresses part of bug #607798
