Comment # 3
on bug 105145
from k.philipp@gmail.com
OK, scratch that. Our VAAPI weave implementation uses legacy GL features, and we're not very keen to accommodate for fields in separate textures in our general shaders. Here's what we'll do instead (in case someone comes here looking for a workaround): - For 2K video or less: Always do VAAPI postprocessing. If the content turns out to be progressive, we do an unnecessary copy (as the driver has to weave). But it enables us to switch deinterlacing on and off on a per-frame basis - needed not only for toggling deinterlacing on user wish, but also for mixed progressive/interlaced video. If you're very sure there are no interlaced frames anywhere in the video, postprocessing could also be turned off (we're usually not). - For more than 2K video: Start with no VAAPI postprocessing for best performance. If interlaced frames are encountered, activate VAAPI postprocessing and reinitialize decoding with fresh surfaces. This means we'll drop frames and lag around for a bit, but should be OK-ish since >2K interlaced content is very rare. Also, that VAAPI has to weave the first few textures before they've been exported once is not very nice. Is there some kind of hint we could give the driver that we want to have progressive surfaces?
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
