Comment # 30
on bug 98005
from Andy Furniss
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:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
