> the final film needs to be in 10-bit color
HDR is not in your requirement? If you are allowed to use 709 colorspace, then
I do not understand the 10bit requirement. MLT already supports RBG which is 24
bits per pixel. YUV 4:2:2 @ 10bits is only 20 bits per pixel. Maybe you could
use RGB features in MLT, and then use FFMpeg for the final conversion from RGB
to YUV 10bit.
Also, sometimes people confuse 10bit production with 10bit encoding. 8bit
sources can be encoded using 10bit encoding to avoid common encoding artifacts
like banding. If your only requirement is 10bit encoding, then use whatever
tool you want in 8bit and then export in 10bit. Melt supports 10bit encoding
today.
~Brian
On Sunday, April 25, 2021, 03:35:42 AM CDT, amindfv--- via Mlt-devel
<mlt-devel@lists.sourceforge.net> wrote:
I hope it didn't seem that I (the original author) was doing the badgering!
My situation is that I have a project I'd very much like to be able to use
Shotcut or Kdenlive for, but the final film needs to be in 10-bit color.
My hope was to use Shotcut/Kdenlive, possibly in 8-bit and then rendering with
melt in 10-bit. This would involve mostly simple cuts and a small set of
filters and/or transitions.
I understand the desire not to start building something that likely won't be
the long-term solution, but I can only assume the redesign of MLT's internals
to fully support >8 bits will take quite a long time. (Tthis is not a criticism
- I mean that coming up with a thorough plan for the future takes time).
If we could come up with some limited scope that'd be acceptable to build out a
shorter-term partial solution, I'd be happy to work on it to the best of my
abilities.
My other course of action seems to be to find a 10-bit rendering pipeline
elsewhere (Gstreamer, Blender?), and either work in Shotcut/Kdenlive 8-bit and
use OTIO or a custom converter to go from .mlt to the renderer, or to just use
another editor (Pitivi? Blender? Olive?).
Any thoughts greatly appreciated!
Thanks,
Tom
On Mon, Apr 19, 2021 at 10:26:52PM -0700, Dan Dennedy wrote:
> On Mon, Apr 19, 2021 at 9:29 PM amindfv--- via Mlt-devel <
> mlt-devel@lists.sourceforge.net> wrote:
>
> > Pull request #634 ("avformat producer: 10- and 16-bit color support") has
> > been closed as invalid on Github. Is this simply because the PR's becoming
> > stale, or does it mean MLT's going in a different direction in terms of
> > supporting (or not supporting!) bit depths greater than 8 bits per
> > component, HDR, etc? Cameras producing higher bit depths are not just
> > becoming more common - it's the norm for new cameras. (On the B&H website 9
> > of the top 10 top selling cameras do).
> >
>
>
> I closed it as invalid because it was inadequate, not aligned with any
> strategy, and opens the door to people adding 10 bit to our existing code,
> which is not a good solution.
>
> There is no strategy yet, but everyone here surely acknowledges the value
> of more than 8 bits. Making a token PR and badgering the current developers
> does not help. Brian and I have discussed prototyping a few things, but we
> have not started and have been focusing on closure of things from the
> previous year. It is not clear how nor easy to take the next great leap
> when considering all the factors.
>
> MLT new major version 7 is about to be released, and there will be some bug
> fixing to follow. We hope to start our prototypes soon after.
>
>
>
> > Thanks,
> > Tom
> >
> >
> > _______________________________________________
> > Mlt-devel mailing list
> > Mlt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mlt-devel
> >
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
