GNOME Bugzilla – Bug 742831
GstEncodingProfile should take multiple presets
Last modified: 2018-11-03 11:34:04 UTC
The encoding API provided by GstEncodingProfile only allows for a single GstPreset to be attached to it. This means that we must know, before hand, what encoder will be used, which defeats the point of the encoding API. Ideally, we should allow the provision of multiple presets to the GstEncodingProfile, probably with an associated GstElementFactory name. This would allow us to select the appropriate preset based on what is available on the system, and apply that. Even better would be for the saved preset itself to have the associated factory name -- that way we would just walk down the list of provided presets and try to apply them till one works. Relatedly, the GstEncoding*Profile should probably use properties for initialisation and getting/setting parameters.
> This means that we must know, before hand, what encoder will be used, which defeats the point of the encoding API. To expand on this, while it's true that presets by definition are encoder-specific, in cases where multiple implementations for an encoded caps exist (x264/openh264 or voaacenc/faac, etc), it would be good to be able to specify presets for each of these and allow encodebin to choose whichever is available (or is higher priority).
Just to throw in some ideas, the preset-api allows arbitrary tag=values attached to a preset as string metadata. I mostly use comment='description of preset. But we could also define extra tag (e.g. 'realtime'), by which encodebin can lookup matching presets for encoders.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/153.