> > Am I (at all) on the right track here?: > > > > Yes! > > > > This code seems to say the avformat producer supports rgba, rgb24, and > > yuv422p? > > https://github.com/mltframework/mlt/blob/master/src/modules/avformat/producer_avformat.c#L614-L630 > > > > This is a better place to look: > > https://github.com/mltframework/mlt/blob/master/src/modules/avformat/producer_avformat.c#L1167rgba, > > rgb24, yuv420p, yuyv422 > > Got it, thanks! So AVPixelFormat is the ffmpeg(?) pixel format, and > mlt_image_format is the type actually used by MLT services (or, at least, by > filters and transitions)?
Yes. > The definition of mlt_image_format >(https://github.com/mltframework/mlt/blob/master/src/framework/mlt_types.h#L45-L58) > seems to have only mlt_image_yuv422p16 as a candidate capable of supporting >10-bit color; is > that right? All the rest (excluding glsl which I haven't >explored) seem to only be 8-bit? Yes. > And also is my math right that it is in fact able to support 10(+) bits of >color? - i.e. 2 chroma-subsampled pixels have (32 bpp*2==64) bits of color >information, divided by 4 (2 Y + 1 Cr + 1 Cb) == 16 bits per component? > A simpler way of saying this might be: the ffmpeg naming scheme for e.g. >"yuv422p10le" is the same as MLT's naming scheme for "yuv422p16", thus since >16 is greater than 10, we can definitely losslessly use 10-bit > colors (in >services that support 16-bit colors)? No. yuv422p16 is 16 bits per sample (32bits per pixel) because we prefer to operate on byte boundaries in MLT. It maps to AV_PIX_FMT_YUV422P16LE. https://github.com/mltframework/mlt/blob/master/src/modules/avformat/consumer_avformat.c#L591 ~BM
_______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
