On 21.10.24 23:50, James Almer wrote:
On 10/21/2024 5:44 PM, James Almer wrote:
On 10/21/2024 4:57 PM, Martin Schitter wrote:
+ break;
+ case MKTAG('y','2','1','0'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_YUV422P10LE, 20, unpack_y210);
Y210 has no pixel format, and it's packed, not planar, so definitely
not AV_PIX_FMT_YUV422P10LE.
Nevermind, there's AV_PIX_FMT_Y210.
Although both entities share a very similar FOURCC code, they are very
different bit structures in practice!
Sure, both of them refer 'somehow' to 10bit 4:2:2 YUV data and can be
lossless converted in both directions, but that's all they have in common.
But in fact I could have converted the DNxUncompressed 10 and 12 bit
formats to any packed format as well. I just choose the planar variant,
because byte ordering changes are easier to handle in this arrangement
and there were more systematically ordered variants of this kind already
defined. At the beginning I hopped, that this would make the reuse of
already defined pixformats more easily and also enable a more
consistent code layout for all the required RGB / YUV422 / YUV444
variants...
Searching the chaotic list of already defined pixel formats is another
topic, where I better keep quiet, because I could otherwise hurt somebody...
Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
