[x264enc] - How can i set any parameters that is supported in x264cli with gst?

[IamTrying]

All parameters are here: http://mewiki.project357.com/wiki/X264_Settings#profile

Q. How do i set all those settings when i need it?

For example how do i apply this following setting with gst x264enc? Gst i got only boolean true/false instead of having a way to put strict or none etc.

Example:

b-pyramid
Default: normal
Allow the use of B-frames as references for other frames. Without this setting, frames can only reference I- or P-frames. Although I/P-frames are more valued as references because of their higher quality, B-frames can also be useful. B-frames designated as references will get a quantizer halfway between P-frames and normal B-frames. You need to use at least two B-frames before B-pyramid will work.
If you're encoding for Blu-ray, use 'none' or 'strict'.
none: do not allow B-frames to be used as references.
strict: allow one B-frame per minigop to be used as reference; enforces restrictions imposed by the Blu-ray standard.
normal: allow numerous B-frames per minigop to be used as references.
See also: --bframes, --refs, --no-mixed-refs

[Tim-Philipp Müller-2]

On Mon, 2012-03-05 at 08:07 -0800, IamTrying wrote:

> All parameters are here:
> http://mewiki.project357.com/wiki/X264_Settings#profile
>
> Q. How do i set all those settings when i need it?
>
> For example how do i apply this following setting with gst x264enc? Gst i
> got only boolean true/false instead of having a way to put strict or none
> etc.
>
> Example:
>
> b-pyramid
> Default: normal
> Allow the use of B-frames as references for other frames. Without this
> setting, frames can only reference I- or P-frames. Although I/P-frames are
> more valued as references because of their higher quality, B-frames can also
> be useful. B-frames designated as references will get a quantizer halfway
> between P-frames and normal B-frames. You need to use at least two B-frames
> before B-pyramid will work.
> If you're encoding for Blu-ray, use 'none' or 'strict'.
> none: do not allow B-frames to be used as references.
> strict: allow one B-frame per minigop to be used as reference; enforces
> restrictions imposed by the Blu-ray standard.
> normal: allow numerous B-frames per minigop to be used as references.
> See also: --bframes, --refs, --no-mixed-refs

Try the "option-string" property.

Cheers
 -Tim

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[pfarmer]

How can I use the option-string? For example
 gst-launch videotestsrc is-live=true ! x264enc option-string="qp=35" ! ffdec_h264 ! xvimagesink --gst-debug=x264enc:5
gives significantly lower qp's (x264enc :0::<x264enc0> frame=   1 QP=11.27 NAL=2 Slice:P)
even its say's:  <x264enc0> Applying option-string: qp=35
But also other options like option-string="bitrate=64" does not work.
Where can I find a documention?

[pfarmer]

There was already a question like mine (sorry):
http://gstreamer-devel.966125.n4.nabble.com/Mapping-ffmpeg-libx264-preset-options-to-x264enc-option-string-parameter-tp3032017p3032017.html

Unfortunately this did not got answered as well.

At least the parsing of the option string at Gstreamer side should work as in the function gst_x264_enc_parse_options in gstx264enc.c. Each parameter is set with the x264_param_parse function declared in x264.h. Options are split at each ":" and option name and value are split at "="; like the ffmpeg x264opts options (http://ffmpeg.org/ffmpeg.html#libx264)

After applying  "option-string property"  "user-set options" are applied in the gstx264enc.

So, is there a bug? Or do I still missing some understanding?

[pfarmer]

It seems a matter of unknown order of applying parameters and presets/tuning

For example this does 2 slices (in 2 NAL units) per frame
$ gst-launch filesrc location=video.mkv ! matroskademux ! x264enc bitrate=128 aud=false  option-string="slices=2" ! rtph264pay ! fakesink --gst-debug=rtph264pay:5,x264enc:5

This does 4 slices per frame (in 4 NAL units) per frame
$ gst-launch filesrc location=video.mkv ! matroskademux ! x264enc bitrate=128 aud=false tune=zerolatency option-string="slices=2" ! rtph264pay ! fakesink --gst-debug=rtph264pay:5,x264enc:5

The tuning parameters should be assigned first and then be overwritten by all other parameters. [man x264]. In the above case the tune=zerolatency adds sliced-threads [source code common/common.c] which forces to use multiple slices.
And my guess is that ALL DEFAULT (or overwritten by the user) parameters others than the option-string are applied to the encoder. This is from a quick look at the source code, which I did not fully examined yet. That means thats all parameters available as gstx264enc parameters must be set there and not in the option-string. In the above example this would be the bitrate paramerter.

Could that be the case???



The test video e.g.:
$ gst-launch videotestsrc num-buffers=10 ! video/x-raw-yuv, format="(fourcc)I420" ! filesink location=video.yuv