[Bug 766050] Add Low power, High performance h264 encoder support

[GStreamer (GNOME Bugzilla)]

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

--- Comment #7 from sreerenj <bsreerenj at gmail.com> ---
(In reply to Gwenole Beauchesne from comment #5)
> (In reply to sreerenj from comment #4)
> > (In reply to Tim-Philipp Müller from comment #3)
> > > Out of curiosity, why was this not added as a flag to the existing "tune"
> > > property? Even more so seeing that it's part of the GstVaapiEncoderTune
> > > flags in the encoder API.
> > > 
> > 
> > Damn, how did i miss it!! Somehow i was thinking tuning property only for
> > Low/Medium/High compression which are based on coding tools like cabac,
> > 8x8dct etc. low-power-mode is something which is using a new hardware block
> > in lower level.  
> > 
> > Surely we should use "tune" options.
> 
> Yes, you should use the tune=low-power option, that was designed as is for
> VDENC too. :) That way, you respect the constraints of VDENC wrt. the
> acceptable set of coding tools.

Good to see the architect back :)

After few discussion with Tim in IRC I was thinking about the possibility to
use flags instead of enum for tuning options.
But there is bit of architectural issue here:

Right now it is not possible to use combination of tuning options . In theory
it is right.
As an eg: high-compression means we can enable more b-frames. low-latency means
we shouldn't use or reduce nunbmer of bframes etc.
We could have similar things in future too. So it doesn't make sense to use
flags instead of enum.

But, the usage of VDENC is different, it can be combined with any of the tuning
options.And it is a needed feature too IMHO.

So for me, the better solution seems to be keep a new property
"high-performance" for enabling vdenc and keep all tuning options which are
based on algorithamic features as it is (enums)

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