Am 26.01.2017 um 16:59 schrieb Peter Frühberger:
2017-01-26 16:36 GMT+01:00 Christian König <[email protected]
<mailto:[email protected]>>:
Am 26.01.2017 um 12:16 schrieb Peter Frühberger:
Hi Christian,
2017-01-26 12:00 GMT+01:00 Christian König
<[email protected] <mailto:[email protected]>>:
Hi Peter,
Am 25.01.2017 um 19:45 schrieb Peter Frühberger:
Peter, Rainer any idea what I'm missing here? Do you
guys use some
modified ffmpeg for Kodi or how does that work for you?
do you set the format correctly, e.g.:
https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L2697
to create the surfaces?
Well the problem here is that the VA-API interface is not
consistent and I'm not sure how to implement it correctly.
See your code for example:
VASurfaceAttrib attribs[1], *attrib;
attrib = attribs;
attrib->flags = VA_SURFACE_ATTRIB_SETTABLE;
attrib->type = VASurfaceAttribPixelFormat;
attrib->value.type = VAGenericValueTypeInteger;
attrib->value.value.i = VA_FOURCC_NV12;
First Kodi specifies that NV12 should be used which implies
that this is a 8bit surface.
// create surfaces
VASurfaceID surfaces[32];
unsigned int format = VA_RT_FORMAT_YUV420;
if (m_config.profile == VAProfileHEVCMain10)
format = VA_RT_FORMAT_YUV420_10BPP;
But then Kodi requests a 10bit surface. Now what is the
correct thing to do here?
I can either create an NV12 surface, which would be 8bit but
would result in either an error message or only 8bit
dithering during decode.
Or I can promote the surface to 10bit, which would result in
a P010 or rather P016 format.
Or and that is actually what I think would be best the VA-API
driver should trow an error indicating that the application
requested something impossible.
Yes you are right. Looks like a driver specific:
https://cgit.freedesktop.org/vaapi/intel-driver/tree/src/i965_drv_video.c#n1338
<https://cgit.freedesktop.org/vaapi/intel-driver/tree/src/i965_drv_video.c#n1338>
seems they use it as a hint to the subsampling: SUBSAMPLE_YUV420
and then later compare with with the format again to choose.
From code pov we should set the attribute to: VA_FOURCC_P010, right?
Yes, I think so.
Christian.
Fixed via:
https://github.com/FernetMenta/kodi-agile/commit/bb73b5535e2f4b65772451c23f75503d04de69ef
thanks for the heads up
Great! Thanks a lot for cleaning that up so quickly.
In that case I will just respond to such nonsense combinations with an
error result.
Christian.
Peter
Regards
Peter
afterwards we just do drm / egl interop, via:
https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1374
<https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1374>
I'm not sure if that will ever work correctly. The problem is
that VA-API leaks to the application what the data layout in
the surface is. As soon as we turn on tilling that will only
work with rather crude hacks.
I will try to get it working, but probably need help from you
guys as well.
Regards,
Christian.
You need ffmpeg 3.2.
If you use vaPutSurface it will end up as RGBA32 or
something, which is why we use the above way.
Best regards
Peter
Cheers,
Christian.
--
Key-ID: 0x1A995A9B
keyserver: pgp.mit.edu
<http://pgp.mit.edu> <http://pgp.mit.edu>
==============================================================
Fingerprint: 4606 DA19 EC2E 9A0B 0157 C81B DA07 CF63 1A99
5A9B
--
Key-ID: 0x1A995A9B
keyserver: pgp.mit.edu <http://pgp.mit.edu>
==============================================================
Fingerprint: 4606 DA19 EC2E 9A0B 0157 C81B DA07 CF63 1A99 5A9B
--
Key-ID: 0x1A995A9B
keyserver: pgp.mit.edu <http://pgp.mit.edu>
==============================================================
Fingerprint: 4606 DA19 EC2E 9A0B 0157 C81B DA07 CF63 1A99 5A9B
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev