Comment # 30 on bug 98005 from
Seems that error is a bit random and not always there.

It's possible with the patches to get corrupted output with cqp, fix seems easy
=
disable the statement -

if (context->desc.h264enc.rate_ctrl.rate_ctrl_method !=
PIPE_H264_ENC_RATE_CONTROL_METHOD_DISABLE

Unerlated observation while testing related to perf = I guess it depends on
stream, but on a raw 2160p60 input from ram, with or without patches, I am more
than twice as fast with init-qp <= 28.

Timing luck loosing me dual instance? Or something more fundamental meaning the
encoder works harder al lower rates?

I notice that unlike omx when using cqp,  some rate control settings are still
filled in.

omx is the same speed with higher qp - and produces bigger files for the same
qp.


You are receiving this mail because: