Commen=
t # 4
on bug 10514=
5
from Christian K=C3=
=B6nig
(In reply to k.philipp from comment #2)
> Since we can do weaving on the Kodi side anyway =
(for VDPAU), would it be
> enough to add flags, say VA_EXPORT_SURFACE_TOP_FIELD and
> VA_EXPORT_SURFACE_BOTTOM_FIELD, to vaExportSurfaceHandle? Would that t=
hen be
> roughly equivalent to what we get with VDPAURegisterVideoSurfaceNV?
Yes, exactly that's what's needed.
(In reply to k.philipp from comment=
#3)
> Here's what we'll do instead (in case someone co=
mes 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 a=
lso
> 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 mea=
ns
> we'll drop frames and lag around for a bit, but should be OK-ish since=
>2K
> interlaced content is very rare.
Sounds like a good plan to me as well.
> Also, that VAAPI has to weave the first few text=
ures before they've been
> exported once is not very nice. Is there some kind of hint we could gi=
ve the
> driver that we want to have progressive surfaces?
Not that I know of, but feel free to suggest something. General problem with
VA-API seems to be that suggestions made by AMD seems to be mostly ignored.
Also don't call it interlaced/progressive (that was just me trying to make
sense of what the hardware is doing).
Instead call it something in the line of FIELD and FRAME, that is the more
common terminology at least in the different MPEG standards.