Comment # 33
on bug 98005
from Andy Furniss
(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.
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
