[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 #45 from Robert Swain <robert.swain at gmail.com> 2010-07-08 18:06:21 UTC ---
Rebased on top of master. Comments 30, 32, 37 points 1 and 3 have been
addressed in the patch that follows.

Comment 37, point 2:

* when parsing (user provided option string), g_strsplit need not return 2
strings; is other code sufficiently prepared to handle some NULL safely?

The x264 API x264_param_parse () handles this. If the value passed to it is
NULL, the value becomes "true". This is so that one can do things like
"something=this:cabac:option=blah" and cabac will be set appropriately.

Point 4 about the x264enc_defaults string: I shall review the defaults and
clarify this string and the deblocking filter parameters that get assigned
directly to x264 in the adjacent code.

Regarding the thoughts about libx264 API versions at the end of comment 31,
using strings for everything that can be parsed by a string (except the
inter-dependent rate control options and those that use other APIs such as the
presets) avoids direct access to libx264 API struct members and so #ifdef-ing
the code becomes unnecessary. However, I do need to make the code just give a
warning rather than erroring out if invalid parameters are encountered as this
will occur if an older x264 is used and the parameter doesn't exist. And of
course I need to protect this new API that is being used.

So, to summarise the TODO list:
- Check defaults and fix x264enc_defaults string.
- Check API version for these newly-used APIs.

After that, I think it should be pretty much good to go... touch wood. :)

-- 
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.