[Bug 796716] encoding: Introduce ih264enc to unify H264 video encoder APIs

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=796716

--- Comment #7 from Thibault Saunier <tsaunier at gnome.org> ---
(In reply to Olivier Crête from comment #6)
> Instead of having this wrapper stuff. Why not make an interface that is
> defined in a document and then use regular properties (ie not a GInterface
> at all)? So for example, we'd document property names like "h264-bitrate",
> "h264-min-qp", "h264-keyframe-interval", "h264-pass", their type and the max
> range that they can have. But each element would just implement each
> property "normally" and for each property, each element would be able to
> expose the min/max that is really supports and it would just work with
> "normal" gst-inspect. We can enforce it with some unit test or gst-validate
> test.

Basically the idea is to be able to uniformize step by step leading to a clean
interface, adding new properties to existing elements would not achieve that
fmpov.

What you describe here doesn't fully work for the same reason a GInterface
without the wrapper doesn't really work , that is:

- How do you handle defaults? For example, you have vaapiench264::bitrate
(kbps)  default = 0 (mean automatic), that can't be changed, so if you add
h264-bitrate, what would be the default? You can't change the current default
of any of the subclasses. The wrapper allow that in a nice way fmpov. 
- You end up with namespacing, making the API harder to understand

Also I believe a GInterface with properties would be cleaner than just a design
doc, why do you think you don't want a GInterface?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.