2016-10-05 16:39 GMT+02:00 Mark Thompson <s...@jkqxz.net>: > On 05/10/16 13:06, Carl Eugen Hoyos wrote: >> >> I cannot test here but afaict, the current implementation of >> vaapi_pix_fmt_from_fourcc() can't be correct.
>> +// FIXME: Take VAImageFormat->byte_order into account >> static struct { >> unsigned int fourcc; >> unsigned int rt_format; > Have you found / had reported to you some case which > causes a problem here? If so, please could you offer some > more detail about it (especially the driver being used). No, I wouldn't even know how to use the code in question. > In the cases I know of, the VAImageFormat structures are > are all hard-coded such that the fourcc is really the only > meaningful information in them: So the byte_order field in VAImageFormat has no meaning and is completely useless? > <https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/image.c#n41> This link was the reason for my mail. > * > <https://cgit.freedesktop.org/vaapi/intel-driver/tree/src/i965_drv_video.c#n246> Not sure if this makes sense... > This is reflected by the use in hwcontext_vaapi.c, which only > fetches the driver's version of the structure in order to pass > it back in vaCreateImage() calls - the other fields are never > touched at all. This sounds as if there is no mapping from VAImageFormat to AVPixelFormat but I misunderstand this, no? > So, I don't think this comment adds any value. Do I understand correctly that one of the RGB formats work correctly on your (little-endian) system (and looks ugly if you replace it with anything else)? Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel