Comment # 11
on bug 105145
from k.philipp@gmail.com
Hi again, > The PR got merged. I do have a patch ready (it's just a few lines anyway), but vaapi has not seen 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 below. In this bug report, I described the approach (or workaround, rather) we took 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 used as post-processing input any more. This could be fixed by setting the export usage hint on the post-processing output surface, since then both input and output 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 you can probably see that in the long run these kind of edge cases will continue 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önig 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 frames 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 streams, 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?
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
