Re: [Mlt-devel] 10-bit color?

2020-11-03 Thread Tom Murphy
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 "-pix_fmt +" [1]
>> to explicitly disallow accidental conversions between formats and color
>> spaces. Is there an option for this in MLT?
> No. Conversions are not "accidental" in MLT and there is no way to disable
> them. The best you can do is to understand the conversions that will occur
> as a frame passes from one service to another and then carefully construct
> your command to avoid using services that will cause conversions that you do
> not want.

Thanks.

Is there an easy way to list (or find) which formats are supported --
and thus don't require conversions -- for inputs and outputs of
filters/transitions?

Tom


___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel


Re: [Mlt-devel] 10-bit color?

2020-07-30 Thread Tom Murphy
> 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 this last bit more clearly as a question:
does the fact it's input 10-bit and output 8-bit imply I _can't_
currently get the data through the whole pipeline 10-bit, or just that
I haven't set whatever config necessary to?

Thanks!
Tom


___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel


Re: [Mlt-devel] 10-bit color?

2020-07-30 Thread Tom Murphy
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 foo.xml -consumer avformat:out.mov

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?)

Thanks,
Tom



On 7/29/20, Brian Matherly  wrote:
> Right now MLT supports a YUV 422 16 bit color format (mlt_image_yuv422p16).
> So 10bit sources can be mapped to that format to avoid bit depth loss. If
> you use any filters or transitions, you will be at the mercy of what that
> particular service requires. Some may convert to RGB, some may convert to 8
> bit YUV. You will have to audit the services you use and then consider if
> they will meet your needs.
>
> MLT does not currently support color remapping for HDR sources. It can pass
> the data through, but you might not get the color results you expect if you
> apply certain filters. If you need to use HDR sources, you might need to
> perform color remapping outside of MLT.
>
> Have you tried to use your new 10-bit files with your current MLT setup?
> Your current setup should work with 10-bit sources, but maybe the bit depth
> will be reduced somewhere in the pipeline. You should try it and see if the
> results are already satisfactory.
>
> ~Brian
>
>
>
>
> On Tuesday, July 28, 2020, 11:10:58 PM CDT, amin...@gmail.com
>  wrote:
>
>
>
>
>
> Hi Brian,
>
> The "modules" term comes from the docs, but roughly what I need is to be
> able to do basic melt (CLI/XML) editing - multitrack, basic cuts, a few
> filters and transitions, including one Movit transition - with footage
> captured from a camera that produces 10-bit 4k video.
>
> Except for the 10-bit part, I've got a MLT setup I'm really happy with at
> the moment. (My previous camera couldn't produce 10-bit color). But if it's
> not realistic to hope for 10-bit color support in the next 6-12 months that
> sort of stops things in their tracks for me and I'll need to figure out
> something else.
>
> Tom
>
>> El 28 jul 2020, a las 23:20, Brian Matherly 
>> escribió:
>>
>> It would be helpful if you could provide more detail about what you are
>> trying to accomplish. What do you mean by "modules" and which ones do you
>> need to use?
>>
>> ~Brian
>>
>>
>> On Tuesday, July 28, 2020, 08:11:52 AM CDT, amin...@gmail.com
>>  wrote:
>>
>>
>>
>>
>>
>> Back when it seemed like a no-brainer I remember breezing by this part in
>> docs/framework.txt: "The framework is designed to be color space neutral -
>> the currently implemented modules, however, are very much YUV422 oriented.
>> In theory, the modules could be entirely replaced."
>>
>> Now, though, I've actually got a camera which produces 10-bit color and
>> I've got a need to use it on a project roughly a year from now. How baked
>> into the cake is this on a practical level? Is anybody working on this
>> problem?
>>
>> 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


Re: [Mlt-devel] Best video format(s) for realtime melt?

2018-12-07 Thread Tom Murphy
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 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 writing to file)?
>
> Although this is admittedly a fuzzy question, I'd imagine criteria for
> "best" being something like:
>   - fast to decode (if not also encode)
>   - parallelizable (it looks like AVCHD can't be decoded multithreaded,
> e.g.)
>   - good on other axes I'm not thinking of, maybe particular to MLT?
>
> Thanks, and apologies for any misapprehensions!
> Tom
>


___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel


[Mlt-devel] Best video format(s) for realtime melt?

2018-12-07 Thread Tom Murphy
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 writing to file)?

Although this is admittedly a fuzzy question, I'd imagine criteria for
"best" being something like:
  - fast to decode (if not also encode)
  - parallelizable (it looks like AVCHD can't be decoded multithreaded, e.g.)
  - good on other axes I'm not thinking of, maybe particular to MLT?

Thanks, and apologies for any misapprehensions!
Tom


___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel