[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 #4 from Jason Garrett-Glaser <darkshikari at gmail.com> 2010-02-01 18:08:47 UTC ---
For the strings, we plan to only allow one preset, but allow multiple tunes as
long as the tunes don't conflict.  The current CLI specifically allows only one
"psy tuning" (e.g. "film" or "animation") but allows mixing that with other,
unrelated tunings ("fastdecode", "zerolatency").

I think it makes the most sense to treat presets/tunes as some sort of
string-based option in Gstreamer.  This would allow anyone to take advantage of
the underlying functionality relatively easily (especially mixing tunes, etc).

Speaking of defaults provided by the underlying library, the current x264enc
has very bizarre defaults that don't match up with libx264.  I can understand
defaulting to faster settings (which makes sense, given that gstreamer is often
used for live applications), but I notice in general that x264enc is often used
"blindly" in Gstreamer pipelines without setting any important parameters. 
This obviously doesn't make sense in most situations since one usually has to
set at least some basic ratecontrol options.

Since presets/tunes are applied before other options, the current system
probably won't make much sense--a preset will be applied, and then all of the
current Gstreamer defaults will override it anyways.  I'm not sure what the
best way to fix this is, since we're not supposed to break API by changing
defaults.

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