https://bugs.freedesktop.org/show_bug.cgi?id=98005
--- Comment #33 from Andy Furniss adf.lists@gmail.com --- (In reply to Boyuan Zhang from comment #32)
Hi Andy,
To summarise your test results, basically you saw the following 3 issues with CQP, is it correct?
- Issue #1. For large clip, sometime you can "invalid GstVaapiCodedBuffer
size (0 bytes)" error.
Turns out I don't need a large clip.
Just running the transcode test above but with vaapih264enc rate-control=cqp init-qp=30 may give this error.
- Issue #2. Random corruption observed when using CQP. Corruption issue is
gone after disable the statement
Issue 1 and 2 are gone with that disabled.
"if (context->desc.h264enc.rate_ctrl.rate_ctrl_method !=PIPE_H264_ENC_RATE_CONTROL_METHOD_DISABLE"
- Issue #3. Encoding speed is twice faster when setting QP<=28
This one was my fault because I forgot to put a ! queue ! in my command and is nothing to do with the patches/not a real issue.
So far I'm lucky enough that my test haven't trigger any of the issue yet. I will spend more time to try from my side. Again, if you could share the commands you were using to trigger the above 3 issue, that would be very appreciated.
In the meantime, I would like to push the 2 patches to upstream first. Because this two patches don't change the behaviour of CQP, but only fixing VBR/CBR. Therefore, I believe CQP fix should be apart from these 2 patches.
CQP works perfectly with vanilla mesa, it is broken by patch 1.