Commen=
t # 33
on bug 98005<=
/a>
from Andy Furniss
(In reply to Boyuan Zhang from comment #32)
> Hi Andy,
>=20
> To summarise your test results, basically you saw the following 3 issu=
es
> with CQP, is it correct?
>=20
> - Issue #1. For large clip, sometime you can "invalid GstVaapiCod=
edBuffer
> size (0 bytes)" error.
Turns out I don't need a large clip.
Just running the transcode test above but with vaapih264enc rate-control=3D=
cqp
init-qp=3D30 may give this error.
> - Issue #2. Random corruption observed when usin=
g CQP. Corruption issue is
> gone after disable the statement
Issue 1 and 2 are gone with that disabled.
> "if (context->desc.h264enc.rate_ctrl.rat=
e_ctrl_method
> !=3DPIPE_H264_ENC_RATE_CONTROL_METHOD_DISABLE"
> - Issue #3. Encoding speed is twice faster when setting QP<=3D28
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 tri=
gger 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 ve=
ry
> appreciated.
>=20
> 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 f=
ixing
> VBR/CBR. Therefore, I believe CQP fix should be apart from these 2 pat=
ches.
CQP works perfectly with vanilla mesa, it is broken by patch 1.