On 10/31/20, Brian Matherly via Mlt-devel
wrote:
> >> That is correct, but beware of automatically-added normalization
> filters
>>> that are added in src/modules/core/loader.ini for things such as scaling
>>> and padding, etc.
>
>> ffmpeg has options like -auto_conversion_filters [0] and
> According to ffprobe, the input video has colorspace 'yuv420p10le'
> (i.e. 10-bit video), but the output is only 'yuv420p'. So it does
> appear somewhere in the pipeline it's being downgraded to 8-bit? (Or
> that there's a default 8-bit output setting somewhere?)
>
Maybe I should have phrased
Great to know there's already some progress loosening the 8-bit max!
I've tried your suggestion of just trying out some 10-bit color videos
with my current setup. What I did was create a simple XML file:
/path/to/file.MOV
avformat
And output it like:
melt
Ah, and another criterion I forgot but could be important is the
ability to quickly seek / jump around in a melt video.
Tom
On 12/7/18, Tom Murphy wrote:
> The "Films By Kris" tutorials recommend using ffmpeg with "-vcodec
> dnxhd" to convert video before handing it
The "Films By Kris" tutorials recommend using ffmpeg with "-vcodec
dnxhd" to convert video before handing it off to melt, because DNxHD
is apparently good for realtime processing with MLT and melt.
Is it (still) the case that DNxHD is the "best" for use with melt in
realtime mode (i.e. not
