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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #11 from Thibault Saunier <tsaunier at gnome.org> ---
(In reply to Olivier Crête from comment #10)
> (In reply to Thibault Saunier from comment #9)
> > (In reply to Olivier Crête from comment #8)
> > > (In reply to Thibault Saunier from comment #7)
> > > > 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?
> > > 
> > > My main problem with a GInterface is that you end up having the same
> > > min/max/etc for all implementations, so you can't use that to document
> > > restrictions.
> > 
> > You can yes.
> 
> How?

Just install the same property on subclasses. 

> > Though the mechanism proposed in this patches "solves" it all and more
> > fmpov. The goal here is to provide one implementation agnostic interface
> > that behaves as similarly as possible whatever the implementation is, the
> > goal being to hide encoder particularities to the end user. What you
> > describe here is not fulfilling those the requirements fmpov. What is your
> > concerned about the proposed approach?
> 
> I dislike the added complexity of the wrapper bin, I find it super ugly.

Implementation wise it looks a bit weird maybe, but complex? Let me disagree.

> And it doesn't offer a way to know which controls are supported by a specific
> encoder and which values are actually valid.. Ideally in a programatic way,
> only including properties that are implemented with the limits that match
> reality sounds like the easiest.

But this is the exact goal of it! Hiding away specificities of of each
implementation is what we want here, if you want to know about them, then don't
use that API.

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