On VAAPI vs libx264

[Ezequiel Garcia]

On 22 July 2016 at 07:50, Sreerenj Balachandran <bsreerenj at gmail.com> wrote:
>
>
> On Fri, Jul 22, 2016 at 10:31 AM, Víctor M. Jáquez L. <vjaquez at igalia.com>
> wrote:
>>
>> On 07/22/16 at 02:43am, Ezequiel Garcia wrote:
>> > Currently, I am using libx264 to encode analog videos on a video server
>> > product.
>> > I'm near the CPU limit, so I was considering switching to vaapi-based
>> > encoding.
>> > My initial experiments were *very* promising, as my CPU went down like a
>> > sack
>> > of potatoes
>> >
>> > The only issue I found so far is that file size is greatly increased
>> > (around 4 times bigger!), yet I'm unable to tune vaapih264enc
>> > to match libx264.
>>
>> Sree can give more details about this than me, but as far as I know,
>> gstreamer-vaapi generates a lot of I frames with small GOP and that is
>> because
>> on how gstreamer-vaapi encoders were written originally.
>>
>> But Sree right now  is working to improve this.
>
> Unfortunately We don't have rich set of tuning options like x264 , but we
> will improve this in future.
>
> For GOP adjustments, currently we only have "max-bframes" property.You might
> have already experimented with it :)
>
> There are few options to reduce the file size,
> -- enable cabac (no need if you are using git master of gstreamer-vaapi
> where cabac enabled by default)
> -- increase max-bframes value
> -- increase the init-qp value
>
> Some works to add hierachical encode is on going:
> https://cgit.freedesktop.org/~sree/gstreamer-vaapi/log/?h=svc
>

Hi guys,

Thanks for the reply!

So, just to clarify: this limitation is in the gstreamer plugin, not
in the vaapi
encoder per se?

The distinction is important for me as it's the difference between
dropping this effort, or putting it on hold until this is fixed/improved.
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar