Commen=
t # 4
on bug 10220=
3
from dwagner
(In reply to Andy Furniss from comment #3)
> Does it help if you set the env
>=20
> VAAPI_DISABLE_INTERLACE=3D1
Yes! I wonder how "interlace" is still a thing so many years afte=
r CRTs became
obsolete, and no interlaced videos were ever involved in my attempts, but
whatever this variable does, it changed the hardware encoding experience fo=
r me
from "crashes all the time" to "does not crash and even prod=
uces a proper video
in about 50% of invocations".
Weirdly, about half of the times I start the very same ffmpeg command line =
for
the very same input file, the output video shows mixed up positions of fram=
es,
as in "not frames 1-2-3-4-5-6 but e.g. 1-4-2-3-5-6 shown in sequence&q=
uot;.
> and modify the -vf to look like
>=20
> -vf 'scale=3D1920:1072,format=3Dnv12|vaapi,hwupload'
Works for me as well as my original command line.
> 1072 is a strange height to use though it doesn'=
t hurt my setup.
At one point in time, I got error messages from ffmpeg that the encoder was
incompatible with sizes that are not even multiples of 16 - that's why I
introduced this scaling just for testing. But this scaling is not relevant
anymore, works the same now with or without it.
I think we can close this bug report: While the
distorted-frame-sequence-half-the-times symptom is unpleasant, it's quite
different from "crashing all the time".=20
And now that I experienced that h.264 hardware encoding on an RX 460 (in 4k)
does not even reach realtime speed, it seems to me that I should probably s=
tick
to "x264 -preset ultrafast" for live streaming anyway.