<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#c31">Comment # 31</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>(In reply to Andy Furniss from <a href="show_bug.cgi?id=98005#c30">comment #30</a>) > 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. Hacking them the same made no difference. This turned out to be a gstreamer wierd because I didn't have a ! queue ! before the encoder. > omx is the same speed with higher qp - and produces bigger files for the > same qp. Still makes slightly bigger files (cabac is on for both)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>