[gstreamer-bugs] [Bug 607798] x264enc needs updating to support new features

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=607798
  GStreamer | gst-plugins-ugly | git

--- Comment #42 from Robert Swain <robert.swain at gmail.com> 2010-06-11 16:34:10 UTC ---
(In reply to comment #41)

[...]

> I am particularly talking about the following code fragment, which is the only
> place where x264enc_defaults is actually used:
> ----
>   /* if no preset nor tuning, use property defaults */
>   if (!encoder->speed_preset && !encoder->tunings->len) {
>     if (gst_x264_enc_parse_options (encoder, x264enc_defaults) == FALSE) {
>       GST_DEBUG_OBJECT (encoder, "Failed to parse defaults string");
>       return FALSE;
>     }
>     encoder->x264param.b_deblocking_filter = 1;
>     encoder->x264param.i_deblocking_filter_alphac0 = 0;
>     encoder->x264param.i_deblocking_filter_beta = 0;
>   }
> ----
> Hence, one need not consider the case where a preset is selected, because that
> fails the if condition.  So, again, in the above conditions, it is not clear
> why some are set by a string in _parse_options, and the others set directly a
> few lines below.  [Suffice to say this is hardly critical/problematic, but the
> above fragment does simply evoke "why?"]

Oh, I see. I think that's kind of an accident. I created the x264enc_defaults
string from the property defaults and then edited it as I went along. There
aren't any properties for the deblocking filter parameters, so they're being
set directly via some hard-coded means.

I don't know if this distinction makes sense. Maybe those options should be
merged into the x264enc_defaults string. I don't really mind. Else I can add a
note that these options are being hard-coded because properties don't exist for
them.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.