Comme=
nt # 11
on bug 10514=
5
from k.philipp@gm=
ail.com
Hi again,
> The PR got merged.
I do have a patch ready (it's just a few lines anyway), but vaapi has not s=
een
a release yet so it is unclear which API version it should depend on. Also =
we
have encountered even more corner cases that prompts me to now follow up on=
a
comment to the PR,
=
https://github.com/intel/libva/pull/196#issuecomment-371769757 - see be=
low.
In this bug report, I described the approach (or workaround, rather) we too=
k in
Kodi to get useful vaapi-accelerated playback working on most videos. In the
meantime, we have encountered more edge cases. Namely:
1. The described approach will not work for 1080p HEVC and VP9 videos, since
the AMD decoder does not support the interlaced (field) format for HEVC and=
VP9
(see si_get_video_param) and will re-allocate the decode surfaces to
progressive format when decoding the first picture. Then they cannot be use=
d as
post-processing input any more. This could be fixed by setting the export u=
sage
hint on the post-processing output surface, since then both input and outpu=
t to
post-processing are progressive.
2. We encountered a DVB H.264 PAFF mixed progressive/interlaced video with
resolution 1920x1088, which failed the size check for always inserting
post-processing by a few pixels. This can be fixed by making the check more
lenient.
Now as you see these issues are not unfixable (or un-workaroundable), but y=
ou
can probably see that in the long run these kind of edge cases will continu=
e to
crop up and cause problems. Our alternative workaround would be to always
re-initialize the whole decode pipeline when encountering a change from
interlaced to progressive frames or vice-versa, losing a bunch of already
decoded frames in the pipeline in the process.
As this is also far from optimal and Christian K=C3=B6nig seemed positively=
inclined
to switch to progressive by default, I want to investigate this route after
all. The only missing piece for this to work seems to be de-weaving the fra=
mes
when switching to the interlaced format, and I can have a look at that (can=
't
promise a time frame though).
However, before investing time into that I want to ask if it would be also
possible to go one step even further: Is the interlaced format necessary in=
the
first place? With DVB (or other, but this seems the most common) PAFF strea=
ms,
you will have to reallocate surfaces and weave/de-weave very often, possibly
after few frames. Wouldn't it be more efficient then to ditch the interlaced
format and have post-processing accept progressive-format frames for
deinterlacing, like intel-vaapi-driver seems to do?