<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - VCE dual instance encoding inconsistent since st/va: enable dual instances encode by sync surface" href="https://bugs.freedesktop.org/show_bug.cgi?id=98005#c30">Comment # 30</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - VCE dual instance encoding inconsistent since st/va: enable dual instances encode by sync surface" href="https://bugs.freedesktop.org/show_bug.cgi?id=98005">bug 98005</a> from <a class="email" href="mailto:adf.lists@gmail.com" title="Andy Furniss <adf.lists@gmail.com>"> Andy Furniss</a> <pre>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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>