On 22 April 2018 at 12:46, Mark Thompson <s...@jkqxz.net> wrote: > On 21/04/18 23:29, Carl Eugen Hoyos wrote: > > 2018-04-21 23:33 GMT+02:00, Rostislav Pehlivanov <atomnu...@gmail.com>: > >> On 21 April 2018 at 21:24, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > >> > >>> 2018-04-20 6:30 GMT+02:00, Rostislav Pehlivanov <atomnu...@gmail.com>: > >>> > >>>> + [AV_PIX_FMT_P010] = > >>>> VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16, > >>> > >>>> + [AV_PIX_FMT_YUV420P10] = > >>>> VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16, > >>> > >>> I don't think both can be correct (unless "PACK16" has no meaning). > > > >> They're both correct and work. > > > > That's really strange... > > (Could this be a bug in the driver?) > > Sounds like it must be a bug somewhere. > > The Vulkan specification says: > > """ > VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16 specifies a unsigned > normalized multi-planar format that has a 10-bit G component in the top 10 > bits of each 16-bit word of plane 0, and a two-component, 32-bit BR plane 1 > consisting of a 10-bit B component in the top 10 bits of the word in bytes > 0..1, and a 10-bit R component in the top 10 bits of the word in bytes > 2..3, the bottom 6 bits of each word set to 0. > > VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16 specifies a unsigned > normalized multi-planar format that has a 10-bit G component in the top 10 > bits of each 16-bit word of plane 0, a 10-bit B component in the top 10 > bits of each 16-bit word of plane 1, and a 10-bit R component in the top 10 > bits of each 16-bit word of plane 2, with the bottom 6 bits of each word > set to 0. > """ > > Which I think makes it pretty clear that > VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16 > is indeed P010 but VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16 > isn't YUV420P10 because they pack the 10 bits at different ends of the > 16-bit value. If a driver is getting that wrong then it should be reported > to the vendor. > > I don't see any formats at all in the Vulkan specification which put the > value at the low end of a containing word, but I might not be looking in > the right place? > > - Mark > > > (Vaguely related, because it made me look it up, it appears that the > device will always match host-endianness: > > After talking about the numeric types, > """ > The representation and endianness of these types on the host must match > the representation and endianness of the same types on every physical > device supported." > """ > > I don't know what that actually means for little-endian graphics cards > (e.g. AMD/Nvidia) in big-endian machines (e.g. POWER) - maybe Vulkan just > doesn't support that, or maybe the driver can fix it up somehow - but we > don't need to think about it at all.) > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
Something's weird: _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
