Comment=
# 4
on bug 98005<=
/a>
from Boyuan Zhang
(In reply to Andy Furniss from comment #3)
> (In reply to Boyuan Zhang from comment #2)
> > Hi Andy,
> >=20
> > The corruption/out of order issue has been reproduced locally. Ro=
ot cause
> > and fix can be found at
> > https://lists.freedesktop.org/archives/mesa-dev/2016-Oc=
tober/132268.html
> >=20
> > Please give a try.
> >=20
> > Regards,
> > Boyuan
>=20
> Thanks, that does fix the out of order and corruption.
>=20
> As you explained in the thread above, dual instance bitrate control is=
a
> separate issue, but this patch does change behavior a bit.
>=20
> cbr is unaffected by patch and could be seen as OK (unless I find a be=
tter
> test to break it). md5sums may vary but the bitrate/file size is only
> different by a tiny amount and visually things seem OK.
>=20
> vbr is different, before patch it may be OK, but there was a chance of=
some
> files being less that half size/rate than they should.
>=20
> With the patch it seems that they are all now less than half rate. So =
at
> least it's consistent (md5sums do still vary).
>=20
> Will test more tomorrow as it's late here.
Hi Andy,
Regarding to the bitrate/file size issue, I didn't see it with my local tes=
ts.=20
For example, "vaapih264enc rate-control=3Dcbr bitrate=3D15000" an=
d "vaapih264enc
rate-control=3Dvbr bitrate=3D21428" will give me almost same output fi=
le size,
which is expected results since 21428*70%=3D15000.
Maybe the command/clip we tested are different. Can you share the command &=
amp;
clip where you saw vbr got half of the expected value please?
Regards,
Boyuan