Yes - as long as:* You do not use any transitions* You do not use any filters
- including normalizing filters - each clip must perfectly match the profile to
avoid normalization filters.
On Monday, November 16, 2020, 11:45:46 PM CST, [email protected]
<[email protected]> wrote:
On Tue, Nov 17, 2020 at 04:40:54AM +0000, Brian Matherly wrote:
> Yes. I expect that would get you very far. Then, you could probably do a
>round trip as long as there are no conversions needed between producer and
>consumer.
Awesome. And this would be enough, right, for Edit Decision List-style editing
with producers and playlists of entries taken from the producers?
Tom
> ~Brian
>
> On Monday, November 16, 2020, 10:06:21 PM CST, [email protected]
><[email protected]> wrote:
>
> On Wed, Nov 11, 2020 at 12:18:02AM +0000, Brian Matherly wrote:
> > > > 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
> >
>
> Thanks, all of this has been really helpful!
>
> Would adding 10-bit color support to the avformat producer "just" mainly
> involve adding code like the below to producer_avformat.c, or is there a lot
> more to it?:
>
> ----------
>
> Adding cases to the switch statement in `pick_pix_fmt`:
>
> case AV_PIX_FMT_YUV420P16LE:
> case AV_PIX_FMT_YUV422P16LE:
> case AV_PIX_FMT_YUV420P10LE:
> case AV_PIX_FMT_YUV422P10LE:
> return AV_PIX_FMT_YUV422P16LE;
>
> ----------
>
> Adding cases to `pick_image_format`:
>
> case AV_PIX_FMT_YUV420P16LE:
> case AV_PIX_FMT_YUV422P16LE:
> case AV_PIX_FMT_YUV420P10LE:
> case AV_PIX_FMT_YUV422P10LE:
> return mlt_image_yuv422p16;
>
> ----------
>
> Adding a case to `convert_image`
>
> ----------
>
> Thanks again,
> Tom
>
_______________________________________________
Mlt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mlt-devel