| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | FIXED |
Comment # 4
on bug 102203
from dwagner
(In reply to Andy Furniss from comment #3) > Does it help if you set the env > > VAAPI_DISABLE_INTERLACE=1 Yes! I wonder how "interlace" is still a thing so many years after CRTs became obsolete, and no interlaced videos were ever involved in my attempts, but whatever this variable does, it changed the hardware encoding experience for me from "crashes all the time" to "does not crash and even produces 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 frames, as in "not frames 1-2-3-4-5-6 but e.g. 1-4-2-3-5-6 shown in sequence". > and modify the -vf to look like > > -vf 'scale=1920:1072,format=nv12|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". 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 stick to "x264 -preset ultrafast" for live streaming anyway.
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
