Re: [Mlt-devel] Audio out-of-sync in SDL consumer when using PNG producer

[Dan Dennedy]

On Tue, Nov 28, 2023 at 12:48 PM Iza i Tomek  wrote:

> I use melt 7.4.0, which came with my Linux Mint.
>
> I'm not sure whether I found a bug, a feature ;-)  but I found it
> very strange.
>
> I use MLT with XML (mlt) files, and some presents in dv_custom file.
>

What exactly is "dv_custom" file? If presets, for what? If a "profile" in
the manner in which MLT uses that terminology, how are you supplying it?


>
> Let's assume I'd like to make a movie with an image and an audio. I
> have two separate files: one PNG, and one m4a (audio). Here's my XML
> file:
>
> 
>

This XML is missing a  element.


>   
>   
>
>   
> 
>   
>
>   
> 
>

These time values are frame counts. But actual time depends on the frame
rate in the consumer or profile.


>   
>
>   
> 
>   
>   
> 
>   
>
> 
>
> It can be rendered to mp4 with the command:
>
> melt file.xml -consumer avformat:"video.mp4" acodec=aac vcodec=libx265 \
>   width=1280 height=720 frame_rate_num=30 frame_rate_den=1 frequency=48000
> \
>

OK, here is your explicit frame rate: 30 fps.


>   progressive=1 display_aspect_num=16 display_aspect_den=9 \
>   sample_aspect_num=1 sample_aspect_den=1
>
> And the produced video.mp4 file is fine.
>
> When I use SDL consumer, though:
>
> melt file.xml
>

You have not provided a profile or consumer frame rate properties. Thus,
melt tries to guess. But since none of your media has a frame rate (video
does), it falls back to using the 25 fps in the dv_pal profile.


>
> the audio is out-of-sync with the clip-audio specified in the XML file.
>
>
Be careful with the term "sync" as that implies the relative timing of
multiple things such as audio and video. How do you know there is a
synchronization problem between audio and a still image? Maybe you mean the
"timing" for the audio producer is incorrect. Remember, frame units depend
on frame rate.


> I have found a weird workaround for that problem, though. When I make
> a short video sequence from the PNG file:
>
> melt file.png out=30 -consumer avformat:"file.mp4" vcodec=libx265 \
>   width=1280 height=720 frame_rate_num=30 frame_rate_den=1 \
>   progressive=1 display_aspect_num=16 display_aspect_den=9 \
>   sample_aspect_num=1 sample_aspect_den=1
>
> and use a single frame from this video in XML file, instead of PNG
> file producer:
>
> 
>   
>frame="1" />
>
>   
> 
>   
>
>   
> 
>   
>
>   
> 
>   
>   
> 
>   
>
> 
>
> everything is fine in both rendered video.mp4, and in the SDL
> preview/consumer.
>
> Now, the melt command line utility has a video with a frame rate to guess
that the sdl(2) consumer should run at 30 fps and timing information in the
XML that uses frame values is based on 30 fps.


> Is it a problem with SDL consumer, or am I doing something wrong?
>

Put a named "profile" attribute in the  element or place a 
element as the first child of the  element.
I am sorry that our documentation is a little weak in this area by not
mentioning XML on the profiles page or profile on the XML page. However, if
you use any tool that uses MLT and generates XML (including `melt -consumer
xml ...` or Shotcut), then you would have seen that.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Running mlt++ without the x11

[Dan Dennedy]

On Wed, Nov 22, 2023 at 7:45 AM Paweł Mruzek  wrote:

> Hello,
> I was wondering, if it's possible to perform video
> editing programmatically with mlt++ without the need for tools
> like xvfb-run to run the app? I believe melt can be built without the qt
> plugins, that seem to be causing the need for x11, but I still
>

Only certain modules like Qt or old WebVfx require X11.


> can't seem to understand if it's possible to get the c++ library to work
> without such tools. I tried to build it with cmake to play around, but I'm
> also stuck on building the `producer_avformat.c.o`:
>
> ```
> [ 50%] Building C object
> src/modules/avformat/CMakeFiles/mltavformat.dir/producer_avformat.c.o
>
> mlt/src/modules/avformat/producer_avformat.c:1523:42: error: ‘struct
> producer_avformat_s’ has no member named ‘vfilter_graph’
>

Do not use git master of FFmpeg as they may have broken their API since the
last release. We have daily tests that build with versions 6.0 and 6.1.



>  1523 | avfilter_graph_free(>vfilter_graph);
>
> mlt/src/modules/avformat/producer_avformat.c:1524:21: error: ‘struct
> producer_avformat_s’ has no member named ‘vfilter_out’
>  1524 | self->vfilter_out = NULL;
> ```
> It might be due to some unmet dependencies, but I felt, that I still
> needed to ask this question if it's possible before going further.
>
> Sorry if my question is not asked well, and thanks for any help in
> advance.
>
>
> ___
> 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] Fwd: Bug#1051570: mlt: FTBFS with RtAudio 6

[Dan Dennedy]

Fixed in git, supports old (4) and new versions.
See also https://github.com/mltframework/mlt/issues/930


On Thu, Oct 12, 2023 at 6:34 AM Patrick Matthäi via Mlt-devel <
mlt-devel@lists.sourceforge.net> wrote:

> Hello,
>
> I have got this patch for RTAudio 6 "support" (not tested, but it builds
> with 7.18.0). This patch also applies to the 7.20.0 version.
> The problem is with the patch applied mlt builds against rtaudio 6.0.1,
> but it fails against 5.2.0 just with:
>
> [ 57%] Linking CXX shared module ../../../out/lib/mlt/libmltmovit.so
> cd /build/mlt-7.20.0/obj-x86_64-linux-gnu/src/modules/movit &&
> /usr/bin/cmake -E cmake_link_script CMakeFiles/mltmovit.dir/link.txt
> --verbose=1
> /usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/build/mlt-7.20.0=.
> -fstack-protector-strong -fstack-clash-protection -Wformat
> -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2
> -Wl,-z,relro -Wl,-z,now -shared  -o ../../../out/lib/mlt/libmltmovit.so
> CMakeFiles/mltmovit.dir/factory.c.o
> CMakeFiles/mltmovit.dir/filter_glsl_manager.cpp.o
> CMakeFiles/mltmovit.dir/filter_movit_blur.cpp.o
> CMakeFiles/mltmovit.dir/filter_movit_convert.cpp.o
> CMakeFiles/mltmovit.dir/filter_movit_crop.cpp.o
> CMakeFiles/mltmovit.dir/filter_movit_deconvolution_sharpen.cpp.o
> CMakeFiles/mltmovit.dir/filter_movit_diffusion.cpp.o
> CMakeFiles/mltmovit.dir/filter_movit_flip.cpp.o
> CMakeFiles/mltmovit.dir/filter_movit_glow.cpp.o
> CMakeFiles/mltmovit.dir/filter_movit_lift_gamma_gain.cpp.o
> CMakeFiles/mltmovit.dir/filter_movit_mirror.cpp.o
> CMakeFiles/mltmovit.dir/filter_movit_opacity.cpp.o
> CMakeFiles/mltmovit.dir/filter_movit_rect.cpp.o
> CMakeFiles/mltmovit.dir/filter_movit_resample.cpp.o
> CMakeFiles/mltmovit.dir/filter_movit_resize.cpp.o
> CMakeFiles/mltmovit.dir/filter_movit_saturation.cpp.o
> CMakeFiles/mltmovit.dir/filter_movit_vignette.cpp.o
> CMakeFiles/mltmovit.dir/filter_movit_white_balance.cpp.o
> CMakeFiles/mltmovit.dir/mlt_movit_input.cpp.o
> CMakeFiles/mltmovit.dir/transition_movit_luma.cpp.o
> CMakeFiles/mltmovit.dir/transition_movit_mix.cpp.o
> CMakeFiles/mltmovit.dir/transition_movit_overlay.cpp.o
> CMakeFiles/mltmovit.dir/consumer_xgl.c.o
> -Wl,-rpath,/build/mlt-7.20.0/obj-x86_64-linux-gnu/out/lib: -lm
> ../../../out/lib/libmlt++-7.so.7.20.0 /usr/lib/x86_64-linux-gnu/libX11.so
> ../../../out/lib/libmlt-7.so.7.20.0 /usr/lib/x86_64-linux-gnu/libGLX.so
> /usr/lib/x86_64-linux-gnu/libOpenGL.so
> /usr/lib/x86_64-linux-gnu/libmovit.so /usr/lib/x86_64-linux-gnu/libepoxy.so
> make[3]: Leaving directory '/build/mlt-7.20.0/obj-x86_64-linux-gnu'
> [ 57%] Built target mltmovit
> make[2]: Leaving directory '/build/mlt-7.20.0/obj-x86_64-linux-gnu'
> make[1]: *** [Makefile:139: all] Error 2
> make[1]: Leaving directory '/build/mlt-7.20.0/obj-x86_64-linux-gnu'
> dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j2 "INSTALL=install
> --strip-program=true" VERBOSE=1 returned exit code 2
> make: *** [debian/rules:11: binary] Error 2
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit
> status 2
>
>
> A better fix would be welcome :)
>
>
>  Weitergeleitete Nachricht 
> Betreff: Bug#1051570: mlt: FTBFS with RtAudio 6
> Weitersenden-Datum: Sat, 09 Sep 2023 21:15:01 +
> Weitersenden-Von: IOhannes m zmoelnig 
> 
> Weitersenden-An: debian-bugs-d...@lists.debian.org
> Weitersenden-CC: Patrick Matthäi 
> 
> Datum: Sat, 09 Sep 2023 23:10:59 +0200
> Von: IOhannes m zmoelnig  
> Antwort an: IOhannes m zmoelnig 
> , 1051...@bugs.debian.org
> An: Debian Bug Tracking System 
> 
>
> Source: mlt
> Version: 7.18.0-2
> Severity: serious
> Tags: ftbfs patch
> Justification: fails to build from source (but built successfully in the
> past)
>
> Dear Maintainer,
>
> mlt ftbfs with RtAudio 6 (currently in experimental).
>
> ```
> [ 89%] Building CXX object
> src/modules/rtaudio/CMakeFiles/mltrtaudio.dir/consumer_rtaudio.cpp.o
> cd /build/mlt-zme0kO/mlt-7.18.0/obj-x86_64-linux-gnu/src/modules/rtaudio
> && /usr/lib/ccache/c++ -Dmltrtaudio_EXPORTS
> -I/build/mlt-zme0kO/mlt-7.18.0/src/framework/.. -isystem
> /usr/include/rtaudio -g -O2
> -ffile-prefix-map=/build/mlt-zme0kO/mlt-7.18.0=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++14 -fPIC -mmmx -msse -msse2
> -pthread -D__LINUX_ALSA__ -D__LINUX_PULSE__ -D__UNIX_JACK__ -D_REENTRANT
> -MD -MT
> src/modules/rtaudio/CMakeFiles/mltrtaudio.dir/consumer_rtaudio.cpp.o -MF
> CMakeFiles/mltrtaudio.dir/consumer_rtaudio.cpp.o.d -o
> CMakeFiles/mltrtaudio.dir/consumer_rtaudio.cpp.o -c
> /build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp
> /build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp: In
> member function ‘bool RtAudioConsumer::create_rtaudio(RtAudio::Api, int,
> int)’:
> /build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp:164:26:
> error: ‘struct RtAudio::DeviceInfo’ has no member named ‘probed’
> 164 | 

Re: [Mlt-devel] SDL consumer framerate?

[Dan Dennedy]

On Sun, Sep 24, 2023 at 10:59 AM Iza i Tomek  wrote:

> Is it possible to force a particular framerate for sdl consumer?
>

Yes, using consumer properties
https://www.mltframework.org/doxygen/properties.html
or a profile
https://mltframework.org/docs/profiles/


>
> My original problem is: I have an XML file (MLT) to render by ffmpeg,
> using 30fps. All times are specified in frame numbers, so they depend
> on the framerate.
>

How did you specify the frame rate in XML? It should be specified, or you
are relying on some default or some attempt to guess it. The way you
specify is the same as the answer above.


> The SDL consumer uses a lower framerate (25? I'm not
>

The default profile is 25 fps.


> sure), so my audio is out of sync with my video. (Video is made mostly
> from PNGs). As a result, the SDL consumer is useless.
>

MLT, including melt, is primarily for developers. Maybe you will find one
of the GUI editing apps more useful.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Fwd: Bug#1041664: mlt: FTBFS with ffmpeg 6.0

[Dan Dennedy]

On Tue, Jul 25, 2023 at 9:05 AM Patrick Matthäi via Mlt-devel <
mlt-devel@lists.sourceforge.net> wrote:

> Hey,
> is this known, that there are problems with ffmpeg 6.0? Looks more like
> something with the Python module does not work then
>
>
MLT v7.6 or later is required for FFmpeg 6. Otherwise, no, it has been
working fine.


>
>  Weitergeleitete Nachricht 
> Betreff: Bug#1041664: mlt: FTBFS with ffmpeg 6.0
> Weitersenden-Datum: Fri, 21 Jul 2023 19:21:01 +
> Weitersenden-Von: Sebastian Ramacher 
> 
> Weitersenden-An: debian-bugs-d...@lists.debian.org
> Weitersenden-CC: sramac...@debian.org, Patrick Matthäi
>  
> Datum: Fri, 21 Jul 2023 21:16:51 +0200
> Von: Sebastian Ramacher  
> Antwort an: Sebastian Ramacher 
> , 1041...@bugs.debian.org
> An: Debian Bug Tracking System 
> 
>
> Source: mlt
> Version: 7.16.0-1
> Severity: important
> Tags: ftbfs sid trixie
> X-Debbugs-Cc: sramac...@debian.org
>
> mlt FTBFS with ffmpeg 6.0 (available in experimental):
>
> make[1]: Entering directory '/<>'
> chrpath -d -k /<>/debian/tmp/usr/bin/melt-7
> dh_install
> dh_install: warning: Cannot find (any matches for)
> "usr/lib/python3/dist-packages/*" (tried in ., debian/tmp)
>
> dh_install: warning: python3-mlt missing files:
> usr/lib/python3/dist-packages/*
> dh_install: error: missing files, aborting
> make[1]: *** [debian/rules:15: override_dh_install] Error 25
>
> The full build log is attached.
>
> Cheers
>
> --
> Sebastian Ramacher
>
>
> ___
> 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] Problem with sound when exporting playlist with blanks

[Dan Dennedy]

"transparent" is not a valid color name:  See
https://mltframework.org/plugins/ProducerColor/
It just so happens to work though since it tries to convert the string to
an int resulting in 0, which is equivalent.

The higher order track gets priority when using multitrack, and there is no
automatic blending or mixing of audio.
But the workaround does not need to be so heavy as to require blending with
transparent. Why does Flowblade, Shotcut, and Kdenlive not suffer from this
problem? I am quite certain this used to work in melt without multiple
tracks - probably before the audio pipeline became more powerful and
flexible. These apps automatically add track mixers and include a hidden,
silent, black track:
melt -track color out=75 -track color:red in=0 out=25 -blank 25 color:blue
in=0 out=25 -transition mix -consumer avformat:test.mp4

Now, how can it work without that? The default sample format in MLT is
signed 16-bit (as produced in mlt_frame_get_audio() for frames with dummy
audio). However, avformat consumer tries to render using the selected
codec's default sample format (at some point it did not). The implied codec
of test.mp4 is aac, which is float (mlt_audio_f32le). If we instead change
the audio codec to pcm_s16le and the filename extension to .mov (pcm is not
supported in MP4 by standards and ffmpeg), then it succeeds:
melt color:red in=0 out=25 -blank 25 color:blue in=0 out=25 -consumer
avformat:test.mov acodec=pcm_s16le

In any case, if you play this back you see white frames in between the
colors red and blue. That brings up another point: is that what you expect
in "blank?" In MLT the dummy image for frames is solid white. This was
chosen to facilitate troubleshooting because it should be generally
avoided, and black is too easily overlooked. That is why most MLT apps are
mixing with a silent black track - to explicitly give users black when they
expect it.

I found you are working on your own new video editor
. You are
free to do whatever you want, but I do encourage you to work with one of
the existing projects. I do not want to speak for Brian, but he and I make
Shotcut.


On Mon, Jul 24, 2023 at 4:02 AM Brian Matherly via Mlt-devel <
mlt-devel@lists.sourceforge.net> wrote:

> Yeah. That is a good point. You would need to add a transition so that the
> transparent is blended with the red. I guess it is not a perfect work
> around.
>
> ~Brian
>
>
> On Monday, July 24, 2023 at 12:17:45 AM CDT, Rickard Lindberg <
> rick...@rickardlindberg.me> wrote:
>
>
> Hmm.
>
> Do I need to add some kind of transition for the transparent color to have
> any effect?
>
> I expected both of these to generate 100 (or 101?) red frames:
>
> $ mlt-melt -track color:red in=0 out=100 -track color:transparent in=0
> out=100
> $ mlt-melt -track color:transparent in=0 out=100 -track color:red in=0
> out=100
>
> But the first one only shows black frames for me.
>
> /Rickard
>
> On Mon, Jul 24, 2023, at 06:48, Rickard Lindberg wrote:
>
> Thanks for your support! This workaround works fine for me.
>
> /Rickard
>
> On Sun, Jul 23, 2023, at 00:22, Brian Matherly wrote:
>
>
> > mlt-melt color:red in=0 out=25 -blank 25 color:blue in=0 out=25
> -consumer avformat target=/tmp/export.mp4
>
> Thanks for the example command. I reproduce this and I confirm it is a
> bug. I have filed it here:
> https://github.com/mltframework/mlt/issues/931
>
> As a workaround, you can use transparent clips instead of blank:
> mlt-melt color:red in=0 out=25 color:transparent in=0 out=25 color:blue
> in=0 out=25 -consumer avformat target=/tmp/export.mp4
>
> ~Brian
>
>
> On Friday, July 21, 2023 at 04:30:59 AM CDT, Rickard Lindberg <
> rick...@rickardlindberg.me> wrote:
>
>
> I managed to reproduce the problem with melt:
>
> $ mlt-melt color:red in=0 out=25 -blank 25 color:blue in=0 out=25
> -consumer avformat target=/tmp/export.mp4
> +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
> |1=-10| |2= -5| |3= -2| |4= -1| |5=  0| |6=  1| |7=  2| |8=  5| |9= 10|
> +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
> +-+
> |   H = back 1 minute,  L = forward 1 minute  |
> | h = previous frame,  l = next frame |
> |   g = start of clip, j = next clip, k = previous clip   |
> |0 = restart, q = quit, space = play  |
> +-+
> [libx264 @ 0x7fe9d80023c0] interlace + weightp is not implemented
> [mp4 @ 0x7fe9d8000f40] Using AVStream.codec to pass codec parameters to
> muxers is deprecated, use AVStream.codecpar instead.
> [mp4 @ 0x7fe9d8000f40] Using AVStream.codec to pass codec parameters to
> muxers is deprecated, use AVStream.codecpar instead.
> [aac @ 0x7fe9d8004e40] Input contains (near) NaN/+-Inf
> [consumer avformat] 

Re: [Mlt-devel] How can you detect when an avformat consumer fails?

[Dan Dennedy]

You can receive the event in Python, but the arguments are useless with
special SWIG binding definition. Flowblade uses MLT python binding. You
should consult its code for advice. The regular MLT developers have very
little experience with it.

On Sat, Jul 22, 2023 at 1:00 PM Rickard Lindberg 
wrote:

> After reading a bit about Python and SWIG and reading the source code for
> MLT (src/swig/mlt.i in particular), I think that `consumer.listen` is not
> yet usable from Python. There seems to be no way to register a Python
> function as a callback. The mlt.i file seems to have some special handling
> for events for Ruby though. Perhaps something similar is needed for Python?
>
> But it makes me wonder, is there no way to programmatically detect errors
> from a consumer in Python?
>
>
> /Rickard
>
> On Sat, Jul 22, 2023, at 10:55, Rickard Lindberg wrote:
>
> Hi,
>
> I see that there is a "consumer-fatal-error" event. Should that one be
> used? Or
> is there a property set that indicates status?
>
> Also, I was not able to figure out Python syntax for listening to events.
> Does
> anyone know what arg2 and arg3 is supposed to be below?
>
> consumer.listen("consumer-fatal-error", arg2, arg3)
>
> /Rickard
>
>
> ___
> 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

Re: [Mlt-devel] Recent regression related to audio playback

[Dan Dennedy]

On Tue, Feb 7, 2023 at 8:54 AM Jean-Baptiste Mardelle 
wrote:

> Hi all,
>
> Several users reported problematic playback behavior (freeze on seek)
> lately
> in Kdenlive. Seems like it is related to a recent MLT commit:
> fix #860 audio distortion when starting playback
> https://github.com/mltframework/mlt/commit/
> 49398ce87c7ac4123044188b3d3287705df04213
>
> The freeze can easily be reproduced in Shotcut (and Kdenlive) by simply
> pressing spacebar (to trigger play) while seeking the timeline with the
> mouse
> (you might need to try it 2-3 times to freeze).
>
> Seems like it triggers a race condition and playback is then frozen.
> Reverting
> MLT to just before the problematic commit works fine.
>
> Since I am not very familiar with this part of the code, it would be nice
> if
> someone could have a look.
>
> Thanks a lot,
> Jean-Baptiste


Thanks for reporting it. Will fix or revert within a couple of days.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Need guidance in implementing mlt

[Dan Dennedy]

On Sun, Jan 22, 2023 at 7:07 AM Ashish Kumar  wrote:

> See, what I have done the following steps on my macOS:
>
> -> brew install cmake
> -> brew install melt
> -> cloned this repository https://github.com/mltframework/mlt
>
> Now for these java bindings to work, should I run the code directly in
> https://github.com/mltframework/mlt/tree/master/src/swig/java
> Or are there any further requirements.
>

The java binding is not built by default, and most pre-built packages do
not include any language bindings for MLT other than C++ and Python. As
noted in the README:
"More information on usage is found by viewing `CMakeLists.txt`" CMake is
the most popular build system now for C++, but it does not provide
something like a `./configure --help`! Rather, often the CMakeLists.txt is
simple enough to read and discover the options, and that is the case for
MLT: you need to add `-DSWIG_JAVA=ON` to the command line when calling
cmake to configure the build.


>
> I have tried running commands
> -> cmake .
> -> cmake —build .
> But getting this error
> Undefined symbols for architecture arm64:
>
>
You will need to work through this problem, and it might not be easy. I
have not heard of anyone trying to build MLT with Java for macOS/arm64 that
can just help. I have experience with building on macOS/arm64, but I use
MacPorts and not Homebrew. Does Homebrew provide build dependencies when
installing a package or have separate dev(el) packages like many Linux
systems? Is Homebrew a pure arm64 or a full universal system on Apple
Silicon? If not, then perhaps it is installing some x86_64 only
architecture binaries, but you may be building arm64 only or both. In my
experience, the binary architecture needs to match through the full chain
of linkage dependencies. On MacPorts, I am able to set which architectures
to build including both and to build everything from source; so I can be
sure no x86_64-only binary is included. Honestly, I think this aspect is a
big enough problem that if you are inexperienced you should work on an
Intel system to start and try to get something working. Or, possibly try
working in a x86_64 Linux virtual machine or in a Docker container on your
ARM macOS system.


> I want your help on what approach should I follow for this for the java
> bindings to work.
>
> Thanks
>
>
> On 22-Jan-2023, at 7:41 PM, Brian Matherly 
> wrote:
>
> > Currently what I am thinking is of using swig for the code conversion
> that would change my java code to c/c++ code that mlt will use.
>
> I hope you mean the other way around - make Java bindings for MLT so that
> you Java application can use it.
>
> MLT already has Java bindings using SWIG:
>
> https://github.com/mltframework/mlt/tree/master/src/swig/java
>
> ~Brian
>
>
> On Sunday, January 22, 2023 at 07:27:47 AM CST, Ashish Kumar <
> ash...@racloop.com> wrote:
>
>
> Hi there,
> I want to implement this mlt framework in java, for various video editing
> things. Can you guide me a way through it.
>
> Currently what I am thinking is of using swig for the code conversion that
> would change my java code to c/c++ code that mlt will use.
> Correct me if I am wrong.
>
> Can you guide me through this.
> Thanks
>
> ___
> 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

Re: [Mlt-devel] cairoblend and qtblend regressions

[Dan Dennedy]

On Thu, Nov 17, 2022 at 8:49 AM Jean-Baptiste Mardelle 
wrote:

> On Mittwoch, 16. November 2022 10:27:52 CET Dan Dennedy wrote:
> > On Wed, Nov 16, 2022 at 4:20 PM Julius Künzel
> > 
> > wrote:
>
> Hi,
>
> > > there is also https://github.com/mltframework/mlt/pull/840 worth to
> > > consider for such a bug fix release.
> >
> > That is untested and unconfirmed. Also, cairoblend was reverted before
> > release.
>
> My analysis was incomplete but the cairoblend crash is here and 100%
> reproducible for me with the stated command line in MLT 7.10.0:
>


You are referring to something that is new information. The PR link above
is untested and unconfirmed.


> melt color:red out=100 -track alpha.png out=100 -transition
> frei0r.cairoblend
> -consumer avformat:test.mp4 real_time=-4
>
> Crash is caused by this commit, affecting frei0r - not directly linked to
> cairoblend:
> https://github.com/mltframework/mlt/commit/
> b18f2805809454ce0b331658f86e82b9ce35a634
>
> Reverting MLT to the commit just before this one fixes the crash.
>

And so is the one, but I’ll take a look in a couple of days when I am done
traveling.


> Best regards,
>
> Jean-Baptiste
>
> > Just saw the qtblend commit from a couple of days ago. And all the color
> > animation changes are so fresh. I don’t know, probably before end of
> year,
> > but not real soon.
>
>
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] cairoblend and qtblend regressions

[Dan Dennedy]

On Wed, Nov 16, 2022 at 4:20 PM Julius Künzel 
wrote:

> Hi,
>
> there is also https://github.com/mltframework/mlt/pull/840 worth to
> consider for such a bug fix release.
>


That is untested and unconfirmed. Also, cairoblend was reverted before
release.
Just saw the qtblend commit from a couple of days ago. And all the color
animation changes are so fresh. I don’t know, probably before end of year,
but not real soon.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Problem building mlt 7.10.0

[Dan Dennedy]

On Wed, Nov 9, 2022 at 9:28 PM Patrick Matthäi 
wrote:

>
> Am 09.11.2022 um 14:44 schrieb Dan Dennedy:
> > On Wed, Nov 9, 2022 at 5:27 AM Patrick Matthäi via Mlt-devel
> >  wrote:
> >> Hello,
> >>
> >> I have got problems building mlt 7.10.0 on current Debian sid. It aborts
> >> with:
> >>
> >> -- Found SWIG: /usr/bin/swig4.0 (found version "4.1.0")
> >> -- Found Python3: /usr/bin/python3.10 (found version "3.10.8") found
> >> components: Interpreter Development Development.Module Development.Embed
> >> CMake Error: File
> >>
> /build/mlt-7.10.0/src/modules/glaxnimate/glaxnimate/src/core/application_info_generated.in.hpp
> >> does not exist.
> >> CMake Error at src/modules/glaxnimate/CMakeLists.txt:146
> (configure_file):
> >> configure_file Problem configuring file
> >> Call Stack (most recent call first):
> >> src/modules/glaxnimate/CMakeLists.txt:196
> (mlt_add_glaxnimate_module)
> >>
> >> I have attached the full log/output, I hope you can help 
> > When did you download the tarball? It was updated to add the
> > glaxnimate submodule several hours after the initial release upload,
> > but that was days ago. The claimed missing file is in there and a test
> > build against the release tarball with MOD_GLAXNIMATE=ON succeeds for
> > me.
> >
> > $ tar tvzf ~/src/mlt/mlt-7.10.0.tar.gz | grep application_info_generated
> > -rw-rw-r-- ddennedy/ddennedy   277 2022-09-22 18:33
> >
> mlt-7.10.0/src/modules/glaxnimate/glaxnimate/src/core/application_info_generated.in.hpp
>
> Today, about the tags .tar.gz: https://github.com/mltframework/mlt/tags
>
> We can not use the "release" page in our debian/watch scripts, because
> github introduces some lazy loading there and it is broken for such tools..
>
> But good to know then I will get the tarball. Maybe you want to update
> the tag or make a new release?


No, I cannot control that tar file, and it does not include git submodules.
Neither will I check that code into this git repo. You can also get the
release tar from sourceforge. Or you can turn off the Glaxnimate module in
MLT configuration.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Problem building mlt 7.10.0

[Dan Dennedy]

On Wed, Nov 9, 2022 at 5:27 AM Patrick Matthäi via Mlt-devel
 wrote:
>
> Hello,
>
> I have got problems building mlt 7.10.0 on current Debian sid. It aborts
> with:
>
> -- Found SWIG: /usr/bin/swig4.0 (found version "4.1.0")
> -- Found Python3: /usr/bin/python3.10 (found version "3.10.8") found
> components: Interpreter Development Development.Module Development.Embed
> CMake Error: File
> /build/mlt-7.10.0/src/modules/glaxnimate/glaxnimate/src/core/application_info_generated.in.hpp
> does not exist.
> CMake Error at src/modules/glaxnimate/CMakeLists.txt:146 (configure_file):
>configure_file Problem configuring file
> Call Stack (most recent call first):
>src/modules/glaxnimate/CMakeLists.txt:196 (mlt_add_glaxnimate_module)
>
> I have attached the full log/output, I hope you can help 

When did you download the tarball? It was updated to add the
glaxnimate submodule several hours after the initial release upload,
but that was days ago. The claimed missing file is in there and a test
build against the release tarball with MOD_GLAXNIMATE=ON succeeds for
me.

$ tar tvzf ~/src/mlt/mlt-7.10.0.tar.gz | grep application_info_generated
-rw-rw-r-- ddennedy/ddennedy   277 2022-09-22 18:33
mlt-7.10.0/src/modules/glaxnimate/glaxnimate/src/core/application_info_generated.in.hpp


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

Re: [Mlt-devel] Question about how to change the output frame number in shotcut editor

[Dan Dennedy]

On Tue, Sep 13, 2022 at 11:07 AM 李奥杰  wrote:
>
> Dear Sir/Madam,
> I am a researcher working on video enhancement and I found the mlt 
> framework and shotcut editor really useful for video editing. Recently I'm 
> trying to add my own filters for frame interpolation to mlt and shotcut, 
> which needs to change the source frame rate (fps) of the video. I refered to 
> link_timeremap and doubled the fps by modifying the mlt link profile 
> (frame_rate_num and frame_rate_den). After that, I found the fps did change 
> but the total frame number did not change and only the first half of the 
> video can be played in shotcut (see the attached file). I tried to modify the 
> propoties of mlt producer and service (e.g. length, out, and speed) but it 
> still did not work. So I wonder in which part of mlt code can I change the 
> output frame number so that I can increase the frame rate without changing 
> video duration.
> I would appreciate it very much if I could receive your reply.
>
> Best Regards!
> Aojie

It is not possible for a filter or link to change the length of a
producer. It is the responsibility of the program that creates the MLT
composition to adjust the length as needed. As you can see, Shotcut
does not do that yet for Time Remap, but it does for Properties >
Speed.
Also, please do not attach Microsoft documents to a public mailing
list as they are potential vectors for malware and cannot be opened by
many.


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

Re: [Mlt-devel] optimizing MLT's track compositing

[Dan Dennedy]

On Sat, Sep 3, 2022 at 11:57 AM Brian Matherly via Mlt-devel
 wrote:
>
> Thanks for investigating this topic. Here are some comments from me:
>
> 1) I support an attempt to reduce unnecessary image format conversions. Your 
> focus is on track compositing. But it would also be good if we could find a 
> general pattern that would work for filters as well. Some filters can operate 
> on multiple image formats. But there is not a good way for the filter to know 
> what image format to request from get_image to result in the fewest 
> conversions.
>
> 2) I am not excited about adding more parameters to the get_image function. 
> But I understand this might be a necessary concession to improve efficiency.
>
> 3) I have a long-term vision to replace the current get_image function which 
> takes multiple parameters with a new version that takes a single mlt_image 
> structure. In general, I would like to increase the use of mlt_image objects 
> in the framework. In my current vision, we could add a new get_image function 
> that passes an mlt_image and then create a wrapper that allows legacy 
> services to continue to work until they are converted to use mlt_image. Maybe 
> your suggestion could help to move us in that direction.
>

Just to be clear, his proposal is not to add a function parameter to
either the get_frame or get_image functions. Rather to proactively set
the existing (image) "format" property within each producer's
get_frame function. This can inform downstream services about which
image format they request in a call to mlt_frame_get_image(). The idea
makes some sense, is easy to add, and can even be optional. However,
it seems it can be easily defeated as JB pointed out with "effects can
change the format of a frame." Still, it is a low impact, low effort
change worthy of the experiment. IOW, I am OK with it. Let's see the
PR.

> 4) I had previously thought of an idea to add a new function called 
> get_image_dry_run() (or something like that) which would allow a service to 
> query the next service/producer to find out what format would be returned. I 
> think the function could return the image type (or maybe a list of possible 
> types) that would be returned when the service calls get_image(). The 
> downside to this idea is that someone would need to implement this new 
> function for all services. But maybe there could be a default implementation 
> that would just be a pass-through and we would only need to implement the new 
> function for some key services.
>
> 5) As you mentioned, our current method to find out if an image has any 
> non-zejust ro alpha pixels is to request the alpha mask and then seek for 
> values in the returned mask.. I wonder if an image should have a variable 
> called "alpha_status" that can have one of three values: "alpha", "no_alpha" 
> and "unknown". If the framework is certain that there is no alpha (for 
> example, because it just converted RGB to RGBA), then it would set the status 
> to "no alpha". In the case of unknown, a service could request a full scan of 
> the alpha channel to determine the status. Some accounting would be required 
> to make sure that services are setting the variable appropriately when 
> modifying an image.
>
> 6) It would be good if we had a better way to measure the number of 
> conversions that are occurring on an image/frame for a given configuration. 
> My current thought is that if we can make the use of mlt_image more prolific, 
> then we could add a "conversion_count" variable that gets incremented every 
> time a conversion occurs on the image. Maybe there are other ideas that could 
> help us better understand how many conversions are occuring.
>
> Those are some comments from me. I would be interested in continued 
> development of this optimization since it could have a huge impact on the 
> framework performance.

I do not think most of the above have a good return on investment. The
best way to reduce image conversions is not to require them. I have
been slowly working on that over time in little bites including on the
audio side. For example, one could choose RGB throughout as Movit and
Olive are doing. If there will ever be another high bit depth, high
performance image processing framework plugged in it should be
operating in linear RGB just like these. Of course that necessitates
an input and output conversion even when there is no processing
required, but these can be done quickly now. That could be further
optimized by carrying the original image data and pixel format on a
frame, clearing that when dirtied, and only doing a single conversion
on output if needed. Another approach that can be done within the
existing framework and services is to:

1. identify all YUV only services
2. convert some of these to also handle RGB(A)
3. find suitable replacements for some from libavfilter
4. deprecate the remaining and hide them in the UI to prevent users
from adding them
5. optimize the opaque alpha test functions

Re: [Mlt-devel] scale parameter ignored on commandline

[Dan Dennedy]

On Fri, May 6, 2022 at 9:54 AM Thomas Eimers  wrote:

> Hello,
>
> I am using preview scaling with melt using the  command line.
>
> This works, if the scale setting is part of the XML-File and the melt
> command has no consumer parameter.
>
> For example, `melt input.mlt` with an XML configuration like this:
>
>  max-intra-rate="1000" target="Scrolltext3.webm" threads="0"
> real_time="-4" mlt_service="avformat" vcodec="libvpx" quality="good"
> acodec="libvorbis" vb="0" in="0" out="1519" scale="0.1" />
>
> But when I attach a consumer, the scale parameter from the XML-File is
> ignored.
>
>
That is normal and expected since the consumer in the XML is not being
used. This will not be changed.


> So, both commands are not working.
>
>   *
>
> melt example.mlt -consumer
> avformat:icecast://source:secure@icecast:8000/example.webm
>
>   *
>
> melt example.mlt -consumer
> avformat:icecast://source:secure@icecast:8000/example.webm scale=0.1
>
>
>
I just tested it, and it worked for me. You probably have a numeric locale
problem. In versions of MLT before the latest release v7.6.0, melt is
locale sensitive at the command line, but you are probably in a locale that
uses comma for the decimal separator.



> How do I set the scaling on command line with configure a producer?
>
>
> greeting Thomas
>
>
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Have added an SR filter, but exported video can be incorrect

[Dan Dennedy]

On Tue, May 3, 2022 at 7:34 AM Michael Ren  wrote:

> Thanks for your kind reply. In my scenario, a user may randomly try to
> apply a filter to an opened video. If the filter is SR, it means that the
> user needs better resolution of the video (not just linear interpolation).
> The decision is on the fly, and the SR filter should receive the original
> size of the video frame as input, rather than a resized one (produced by a
> default producer with the normalize filter).
>

You should have seen this when viewing filter_resize.c on which you based
your filter. You can stop the automatic scaling by setting frame property
consumer.rescale = "none" before calling mlt_frame_get_image().



> And after manual job is done, the user may export the result video in
> arbitrary resolution.
>
> I have just managed to hack a temporal solution for my problem, that is to
> directly communicate between my SR filter and consumer_avformat.c so that
> my SR filter knows what resolution to export and then resizes the frame to
> the video exporting size inside the filter. This solution works, but the
> logic is ugly and requires more work to generalize.
>

That is wrong and will not be accepted. The user requests the resolution
using the width and height properties on the consumer or MLT profile. These
values will be supplied to your filter's get_image() callback function as
arguments as brian already explained.

Please give a link to your source code for further help. Also, what are the
dependencies and license of your filter. It requires its MLT module if you
are adding new library dependencies.


>
> Brian Matherly  于2022年5月3日周二 10:04写道：
>
>> I think you will need to give more information about what you are trying
>> to accomplish. I do not understand why you would make a filter to double
>> the dimensions of the image.
>>
>> In MLT, the consumer expects to receive the image size that it has
>> requested. The producer has normalize filters (like resize) to ensure that
>> happens. If you want your consumer to receive a different size image, then
>> you should configure your consumer to request that size.
>>
>> On Monday, May 2, 2022, 05:43:49 AM CDT, Michael Ren <
>> renpeira...@gmail.com> wrote:
>>
>>
>> Hey, MLT guys
>>
>> I have added a video SR filter (super-resolution) to MLT, and use it in
>> Shotcut. However, the filter does not work very well. The problem is that
>> the profile width/height from source video (e.g. iw, ih) is different from
>> the frame size after the SR filter processing (e.g. 2*iw, 2*ih), and also
>> the exported video can have another size. As a result, the exported video
>> can be part of the frame generated by my SR filter, if the exported video
>> size is set to be smaller than 2*iw, 2*ih.
>>
>> I code the SR filter, referring to the
>> mlt\src\modules\core\filter_resize.c. Should I move to another reference or
>> should I set some frame property to let the MLT know that the frame size
>> has been changed by my filter?
>>
>> Thank you very much!
>> Best regards
>> ___
>> 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

Re: [Mlt-devel] MSVC build

[Dan Dennedy]

The road map  is mostly wishes
and guesswork especially beyond MLT 7. The main focus of the remainder of
MLT 7 is completion of existing things. There is no technical reason for
the positioning of MSVC, and someone is free to get it working for MLT 7.
And it can be included in MLT 7 as long as it is not too ugly from a
maintenance perspective. I do not know the main difficulties or problems.
As far as pthreads is concerned you can still make it dependent upon that,
and there is a popular port of it to win32 threads that is also available
for use with CMake in vcpkg: https://github.com/microsoft/vcpkg/pull/4081
It is up to your KDE/Windows goals whether to rely upon that or not and
also the depth of any policy. For example, the policy may only apply to KDE
code, and it may be difficult to convert every dependency in the hierarchy
to not use pthreads.



On Sat, Jan 22, 2022 at 11:56 AM Julius Künzel <
jk.kde...@smartlab.uber.space> wrote:

> Hi everybody,
> KDE recently added a Windows CI and we are interested to use it for
> Kdenlive,
> but the CI is based on MSVC and we can't use it at the moment due to MLT
> not
> being able to build with MSVC. I saw that MSVC support is on the roadmap
> for
> MLT 8, however I like to push it by trying to working on it. I wonder if
> beside priorities and time resources there are any technical reasons why
> MSVC
> support is on the roadmap for MLT 8 and not MLT 7? As far as I can see the
> main problem is the use of some POSIX functions mainly from pthread.h?? Do
> you
> already have plans how to replace them or make them build on MSVC? Or is
> the
> whole MSVC build just a general idea yet?
> Cheers,
> Julius Künzel
> Kdenlive Developer Team
>
>
>
>
>
> ___
> 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] Stacking videos vertically

[Dan Dennedy]

I am not going to help further. You need to learn more outside of the code.

On Wed, Jan 5, 2022 at 11:06 AM José María García Pérez <
josemaria.alk...@gmail.com> wrote:

> Could you explain a bit further?
>
> I mean:
> 1. Create profile: p
> 2. Create producer: video1 (with profile p)
> 3. Create producer: video2 (with profile p)
> 4. Read the frame sizes
> 5. Create a new profile with the size of both videos stacked vertically
> 6. Create the consumer with that new profile
>
> So far I am getting funny sizes.
>
> I declared the following function:
> 1. Creates a new profile
> 2. Resize the profile with the size of both videos
> 3. Creates a new tractor and adds the videos as two separated tracks.
> 4. I use an affine filter and applies "oy=height1" to the second track.
> 5. I apply the transition "addition" in order to make both videos visible.
> proc stackVertically( v1,v2:Producer ):tuple[tr:Tractor; p:Profile] =
> # Get an appropriate profile
> var profile = newProfile()
>
> var frame1 = v1.getFrame(0)
> var (width1,height1) = frame1.getImage()
> var frame2 = v2.getFrame(0)
> var (width2,height2) = frame2.getImage()
> profile.setWidth(width1 + width2)
> profile.setHeight(height1 + height2)
>
> # Create the tractor
> var tr = newTractor()
>
> tr.connect( v1, 0 ) # We use the playlist as track0
> tr.connect( v2, 1 )
> var aff = newFactoryFilter(profile, "affine")
> aff["transition.oy"] = height1
> tr.plant(aff, 1)
>
> var compose = profile.newFactoryTransition("frei0r.addition")
> tr.plant(compose, 0, 1)
> return (tr, profile)
>
>
> In order to use this function I do the following:
> 1. Read two videos (in this case I use the same video)
> 2. stack them vertically: the result is the tractor as a producer and the
> new profile
> 3. I create an SDL2 base on the new profile
> 4. Connect the tractor to SDL
> proc main =
> var f = initFactory()
> var p = newProfile("hdv_720_50p")
> var v1 = p.newMedia("./resources/big_buck_bunny_720p_2mb.mp4")
> var v2 = p.newMedia("./resources/big_buck_bunny_720p_2mb.mp4")
>
> var (newProducer, profile) = stackVertically( v1,v2 )
>
> # Consumer
> var sdl = profile.newFactoryConsumer( "sdl2" )
> sdl["terminate_on_pause"] = 1
>
> # From tractor to SDL2
> #v1.attach(aff1)
> newProducer > sdl
>
> # Start the consumer
> sdl.run
>
>
> The result is: https://i.imgur.com/eESDdJg.jpg
>
>
> El mié, 5 ene 2022 a las 18:28, Dan Dennedy () escribió:
>
>>
>> On Wed, Jan 5, 2022 at 9:22 AM José María García Pérez <
>> josemaria.alk...@gmail.com> wrote:
>>
>>> What is the proper way of stacking videos vertically?
>>>
>>> For example:
>>>video1
>>>-
>>>video2
>>>
>>> so that I can later scale it and move it around in the profile.
>>>
>>> Right now I am using affine (scaling down and then positioning it
>>> vertically). But the result is something like:
>>>video1 | black
>>>--
>>>video2 | black
>>>
>>> Basically I am looking how to get a new video which is: (width) x
>>> (2*height)
>>>
>>> You need to make a custom profile.
>>
>
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Stacking videos vertically

[Dan Dennedy]

On Wed, Jan 5, 2022 at 9:22 AM José María García Pérez <
josemaria.alk...@gmail.com> wrote:

> What is the proper way of stacking videos vertically?
>
> For example:
>video1
>-
>video2
>
> so that I can later scale it and move it around in the profile.
>
> Right now I am using affine (scaling down and then positioning it
> vertically). But the result is something like:
>video1 | black
>--
>video2 | black
>
> Basically I am looking how to get a new video which is: (width) x
> (2*height)
>
> You need to make a custom profile.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Does affine transition.rotate_x work?

[Dan Dennedy]

On Sat, Jan 1, 2022 at 2:20 PM José María García Pérez <
josemaria.alk...@gmail.com> wrote:

> I tried the following:
> $ melt -proifle hdv_720_50p -consumer sdl2 +hello.txt -attach affine
> transition.rotate_x="0=0;100=340"
>
> I was expecting to get a rotation animation.
>
>
That property does not support keyframe animation. Not all the properties
do. So this string converts to a number as 0.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Filter affine

[Dan Dennedy]

k...@gmail.com>) escribió:
>
>> I think that my problem is that I am not handling properly nested
>> properties, but before that I don't see the keys a would expect for the
>> "affine" filter:
>>
>> When I print the keys for the affine filter, I get the following:
>>
>> _events
>> mlt_type
>> in
>> out
>> background
>> _unique_id
>> mlt_service
>> _profile
>>
>> I am not seeing neither "transition" nor "use_normalised" keys that I
>> would expect in accordance with
>> https://www.mltframework.org/plugins/FilterAffine/#transition.
>>
>> Any clue about what might be going on?
>>
>>
>> El jue, 30 dic 2021 a las 19:53, José María García Pérez (<
>> josemaria.alk...@gmail.com>) escribió:
>>
>>> I was expecting a rotated image. The output was the video unmodified.
>>>
>>> El jue, 30 dic 2021 a las 19:52, Brian Matherly (<
>>> brian.mathe...@yahoo.com>) escribió:
>>>
>>>> > My first attempt wasn't very successful
>>>>
>>>> What result did you expect, and what was the actual result?
>>>>
>>>> On Thursday, December 30, 2021, 12:28:42 PM CST, José María García
>>>> Pérez  wrote:
>>>>
>>>>
>>>> I wasn't aware about Shotcut doing so. Good to know.
>>>>
>>>> My first attempt wasn't very successful. I did the following:
>>>> # nim c --threads:on -r ex23_loader_video
>>>> import mlt
>>>> import os
>>>> let f = initFactory("/usr/lib/mlt-7")
>>>>
>>>> # Create the consumer
>>>> let p = newProfile("hdv_720_50p")
>>>> var sdl = newFactoryConsumer(p, "sdl2")
>>>>
>>>> sdl["terminate_on_pause"] = 1 # Stop the consumer when finished
>>>>
>>>> # Create via the default producer
>>>> var clip1 = p.newMedia( "./resources/sygic.mp4")
>>>>
>>>>
>>>> var filter = newFactoryFilter(p, "affine")
>>>> filter["transition.fill"] = 1
>>>> filter["transition.distort"] = 0
>>>> filter["transition.rect"] = "339.703 126.468 1430.3 953.532 1"
>>>> filter["transition.valign"] = "middle"
>>>> filter["transition.halign"] = "center"
>>>> filter["transition.threads"] = 0
>>>> filter["transition.fix_rotate_x"] = 340.0
>>>>
>>>> #[
>>>> color:#
>>>> affine
>>>> affineSizePosition
>>>> 1
>>>> 0
>>>> 339.703 126.468 1430.3 953.532
>>>> 1
>>>> middle
>>>> center
>>>> 00:00:00.000
>>>> 00:00:00.000
>>>> 0
>>>> 340.304
>>>>
>>>> ]#
>>>> clip1.attach(filter)
>>>> clip1 > sdl
>>>>
>>>> sdl.start # Start the consumer
>>>>
>>>> while not sdl.stopped:
>>>> sleep(1)
>>>>
>>>> Do you spot something obvious that might be wrong?
>>>>
>>>> El jue, 30 dic 2021 a las 18:52, Dan Dennedy ()
>>>> escribió:
>>>>
>>>> You can use a tool like Shotcut and study it’s XML output to understand
>>>> the properties for a filter. The affine filter is called Size, Position &
>>>> Rotate. To get the XML use File > Save.
>>>>
>>>> On Thu, Dec 30, 2021 at 9:47 AM José María García Pérez <
>>>> josemaria.alk...@gmail.com> wrote:
>>>>
>>>> I don't understand how to use the affine filter:
>>>> https://www.mltframework.org/plugins/FilterAffine/#transition
>>>>
>>>> Could you post a basic C example using it? It would be nice to cover
>>>> both the static and an animation case.
>>>>
>>>> I had the following example about using a filter using Nim:
>>>> import mlt, os
>>>> var f = initFactory()
>>>>
>>>> # Create the default consumer
>>>> var p = newProfile()
>>>> var sdl = newFactoryConsumer(p, "sdl2")
>>>>
>>>> # Create via the default producer
>>>> var clip = newFactoryProducer(p, resource =
>>>> "avformat:/home/jose/Descargas/sygic.mp4")
>>>>
>>>> var filter = newFactoryFilter(p, "frei0r.pixeliz0r")
>>>> filter["BlockSizeX"] = 0.1
>>>> filter["BlockSizeY"] = 0.2
>>>>
>>>> clip.attach( filter )
>>>> clip > sdl
>>>>
>>>> # Start the consumer
>>>> sdl.start
>>>>
>>>> while not sdl.stopped:
>>>> sleep(1)
>>>> ___
>>>> 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

Re: [Mlt-devel] Filter affine

[Dan Dennedy]

You can use a tool like Shotcut and study it’s XML output to understand the
properties for a filter. The affine filter is called Size, Position &
Rotate. To get the XML use File > Save.

On Thu, Dec 30, 2021 at 9:47 AM José María García Pérez <
josemaria.alk...@gmail.com> wrote:

> I don't understand how to use the affine filter:
> https://www.mltframework.org/plugins/FilterAffine/#transition
>
> Could you post a basic C example using it? It would be nice to cover both
> the static and an animation case.
>
> I had the following example about using a filter using Nim:
> import mlt, os
> var f = initFactory()
>
> # Create the default consumer
> var p = newProfile()
> var sdl = newFactoryConsumer(p, "sdl2")
>
> # Create via the default producer
> var clip = newFactoryProducer(p, resource =
> "avformat:/home/jose/Descargas/sygic.mp4")
>
> var filter = newFactoryFilter(p, "frei0r.pixeliz0r")
> filter["BlockSizeX"] = 0.1
> filter["BlockSizeY"] = 0.2
>
> clip.attach( filter )
> clip > sdl
>
> # Start the consumer
> sdl.start
>
> while not sdl.stopped:
> sleep(1)
> ___
> 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] pixbuf

[Dan Dennedy]

You have not included any pixel format or color space converter, and sdl2
does not support rgb. By specifying the producer class as an argument you
bypass the loader producer, which is special.


On Tue, Dec 28, 2021 at 11:01 AM José María García Pérez <
josemaria.alk...@gmail.com> wrote:

> I am playing with pixbuf, but the colours I get are off:
> https://i.imgur.com/DhuBrir.png
> while I was expecting: https://i.imgur.com/p8yTx2W.jpg
>
> The code that I am using (in Nim, but readable):
>
> # nim c -r --threads:on ex02_show_red_window
> import mlt
> import os
>
> var f:Repository = initFactory("/usr/lib/mlt-7")
>
> # Create the default consumer
> var p:Profile = newProfile() #mlt_profile_init(nil)
> var sdl:Consumer = newFactoryConsumer(p, "sdl2")
> sdl["terminate_on_pause"] = 1 # Stop the consumer when finished
>
> var pro:Producer = newFactoryProducer(p, "pixbuf",
> "./resources/pexels-pixabay-97082.jpg")
>
> connect( sdl, pro )
>
> # Start the consumer
> sdl.start
>
> while not stopped( sdl ):
> sleep(1)
>
>
> I have two questions:
> 1. What can I do in order to get proper colours?
> 2. How can I scale the image to fit the profile's size?
>
> Kind regards (and have Christmas holidays!)
> ___
> 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] Nim bindings

[Dan Dennedy]

On Sat, Nov 20, 2021 at 2:01 PM José María García Pérez <
josemaria.alk...@gmail.com> wrote:

> There are a few things under the hood:
> 1. I have several `connect` functions which have different type signatures:
> - For filter:
> https://github.com/mantielero/mlt.nim/blob/51245b9fea6ad1555687ff9229c66ca17a6d3ffb/src/lib/filter.nim#L5-L8
> - For consumer:
> https://github.com/mantielero/mlt.nim/blob/51245b9fea6ad1555687ff9229c66ca17a6d3ffb/src/lib/consumer.nim#L30-L33
> For this functions, I just map: `mlt_filter_connect` with the equivalent
> signature.
>

Oh, that is designed more for use in multitrack scenarios, but I guess that
works. I kind of forgot about it, because it is mainly used by
mlt_field_plant_filter(), which is the more commonly used function in
multitrack command lines, for example, `melt -filter`.


> 2. Given that they work with Service, I just create a number of
> converters. In nim converters, are used to change type automatically. You
> can see for example the following which coverts from Producer to Service
> automatically:
>
> https://github.com/mantielero/mlt.nim/blob/51245b9fea6ad1555687ff9229c66ca17a6d3ffb/src/lib/producer.nim#L8-L10
> This enables using a `Producer` directly with the `connect` function
> without the need of getting previously the Service (that is done
> implicitly).
> 3. I just create the `>` operators in a way that for me make more sense
> visually: from the producer to the consumer. They just call `connect`.
>
> I have wrapped the `mlt_service_attach` function (I wasn't aware of it).
> So now, the following works as well:
>

This corresponds to the `melt -attach` option, and Shotcut uses only this
approach even in multitrack scenarios - attaching to clips, consumer, and
playlists that represent tracks.


> ```
> clip.attach( filter )
> clip > sdl
> ```
>
> https://github.com/mantielero/mlt.nim/blob/master/examples/ex05_filter_frei0r_attach.nim
>
>
> PS: sorry if the wording is not right. I am not a pro developer.
> Regards,
> José M.
>
> El sáb, 20 nov 2021 a las 20:34, Dan Dennedy () escribió:
>
>> Thanks for sharing that. Read more below...
>>
>> On Sat, Nov 20, 2021 at 8:54 AM José María García Pérez <
>> josemaria.alk...@gmail.com> wrote:
>>
>>> I implemented some examples in the Nim programming language. Nim
>>> compiles into C (among other languages).
>>>
>>> I like that it gives you the feeling of python despite it is using
>>> actual types.
>>>
>>> The code looks as follows:
>>> ```
>>> import mlt, os
>>> var f = initFactory()
>>>
>>> # Create the default consumer
>>> var p = newProfile()
>>> var sdl = newFactoryConsumer(p, "sdl2")
>>>
>>> # Create via the default producer
>>> var clip = newFactoryProducer(p, resource =
>>> "avformat:/home/jose/Descargas/sygic.mp4")
>>>
>>> var filter = newFactoryFilter(p, "frei0r.pixeliz0r")
>>> filter["BlockSizeX"] = 0.1
>>> filter["BlockSizeY"] = 0.2
>>>
>>> clip > filter
>>> filter > sdl
>>>
>>>
>>
>> So, the > operator is mapped to both mlt_service_connect_producer() and
>> mlt_service_attach()? I do not understand how the sdl consumer is
>> connecting to the filter because the filter should be *attached* to the
>> producer, and the consumer *connected* to the producer.
>>
>>
>>
>>> # Start the consumer
>>> sdl.start
>>>
>>> while not sdl.stopped:
>>> sleep(1)
>>> ```
>>> As I said, it compiles to C. If compiled in release mode, the executable
>>> only takes 115kb.
>>>
>>> This is just a starting point. You can see some more examples here:
>>> https://github.com/mantielero/mlt.nim/tree/master/examples
>>>
>>> Regards,
>>> José María
>>>
>>>
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Problem with mlt_consumer_is_stopped

[Dan Dennedy]

On Sat, Nov 20, 2021 at 11:35 AM José María García Pérez <
josemaria.alk...@gmail.com> wrote:

> With the following example:
> I never get the `mlt_consumer_is_stopped` set to True.  The played video
> finishes but the exit condition for the while loop is never reached.
>
> Why is that?
>

The end of file does not equal stop. You either need to tell it to stop,
perhaps from another thread or a main event loop. See also the
terminate_on_pause property on the consumer, which I just realized is
under-documented in the API reference and will fix for the next release. It
is however, used in src/examples/play.cpp with a helpful comment.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Nim bindings

[Dan Dennedy]

Thanks for sharing that. Read more below...

On Sat, Nov 20, 2021 at 8:54 AM José María García Pérez <
josemaria.alk...@gmail.com> wrote:

> I implemented some examples in the Nim programming language. Nim compiles
> into C (among other languages).
>
> I like that it gives you the feeling of python despite it is using actual
> types.
>
> The code looks as follows:
> ```
> import mlt, os
> var f = initFactory()
>
> # Create the default consumer
> var p = newProfile()
> var sdl = newFactoryConsumer(p, "sdl2")
>
> # Create via the default producer
> var clip = newFactoryProducer(p, resource =
> "avformat:/home/jose/Descargas/sygic.mp4")
>
> var filter = newFactoryFilter(p, "frei0r.pixeliz0r")
> filter["BlockSizeX"] = 0.1
> filter["BlockSizeY"] = 0.2
>
> clip > filter
> filter > sdl
>
>

So, the > operator is mapped to both mlt_service_connect_producer() and
mlt_service_attach()? I do not understand how the sdl consumer is
connecting to the filter because the filter should be *attached* to the
producer, and the consumer *connected* to the producer.



> # Start the consumer
> sdl.start
>
> while not sdl.stopped:
> sleep(1)
> ```
> As I said, it compiles to C. If compiled in release mode, the executable
> only takes 115kb.
>
> This is just a starting point. You can see some more examples here:
> https://github.com/mantielero/mlt.nim/tree/master/examples
>
> Regards,
> José María
>
>
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] C lang examples

[Dan Dennedy]

It is preferable that bindings are made with the MLT C++ interface. If
possible, then see also the unit tests in src/tests/ in the source tree.

On Sat, Nov 13, 2021 at 12:02 PM Brian Matherly via Mlt-devel <
mlt-devel@lists.sourceforge.net> wrote:

> I think you have been reading the documentation, so I suppose you have
> already seen these pages:
> https://www.mltframework.org/docs/scriptbindings/
> https://www.mltframework.org/docs/codeexamples/
>
> I think the melt CLI application is probably your best option for C
> examples.
>
> I do not have any experience writing language bindings. But I wonder if it
> would be easiest to look at the SWIG output for python and then try to
> model your bindings after that.
>
> ~Brian
>
>
> On Saturday, November 13, 2021, 01:39:50 PM CST, José María García Pérez <
> josemaria.alk...@gmail.com> wrote:
>
>
> I am trying to create some bindings for MLT for the Nim programming
> language.
>
> Is there any place with many C lang examples?
>
> Cheers
> Jose M.
> ___
> 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

Re: [Mlt-devel] Suggestion: declaring "const functions".

[Dan Dennedy]

On Tue, Oct 26, 2021 at 8:04 AM Andre Caldas 
wrote:

> It would be very nice, IMO, if functions like
> "mlt_producer_get_length(mlt_producer self)" were declared in such a
> way that "self" points to a "const".
>
> I find "const" correctness a very useful concept. I guess that users
>

It is on road map for the C++ interface what it's worth
https://www.mltframework.org/changes/todo/

But we have not got around to it due to lack of concern, priorities, and/or
business. You will see that the developers of MLT are also the developers
of Shotcut and Kdenlive, and there are not many of us. If we add some
const-ness, I think it requires a major SONAME change since it changes the
method signatures in mlt++.vers - our compiler symbol versioning file.


> of the MLT library that care for const correctness would benefit.
>
> https://isocpp.org/wiki/faq/const-correctness
>
> Of course, since MLT is already non-const correct, making it so could
> be a nightmare and break things. But simple access methods that do not
> return references should be okay to change. The pointers typedefs in
> "mlt_types.h" makes things a little harder, though. :-(
>
> I think libraries should always be "const-correct", because otherwise
> the library imposes its "non-const-correctness" to their users. It
> affects most the users of the library, more then the library itself.
>
> This is just a suggestion. Most people probably don't really mind.
> Feel free to just ignore this e-mail. :-)
>
> And sorry if this has already been discussed. =o)
>
>
> André Caldas.
>
>
> ___
> 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] DTD: add properties to entries?

[Dan Dennedy]

On Wed, Aug 25, 2021 at 3:18 PM amin...@mailbox.org 
wrote:

> --- a/src/modules/xml/mlt-xml.dtd
> +++ b/src/modules/xml/mlt-xml.dtd
> @@ -77,7 +77,7 @@
>  out  CDATA#IMPLIED
>  titleCDATA#IMPLIED
>  >
> - | transition | chain)* >
> + multitrack | filter | transition | chain)*) >
>producer IDREF#IMPLIED
>  in   CDATA#IMPLIED
>
>
>
Thanks, I made this change in git master branch.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Clock time to frame number?

[Dan Dennedy]

On Tue, Aug 24, 2021 at 6:06 PM amindfv--- via Mlt-devel <
mlt-devel@lists.sourceforge.net> wrote:

> Thank you, this is exactly the type of clear answer I was hoping for!
>
> A couple follow-up questions:
>
>   - I seem to be able to, with the calculation on line 371 linked below,
> get frame-inaccurate results, i.e. dropped or added frames. For example,
> with the simple timecode "01:01:00.1" at 23.976 fps: I think the un-rounded
> value should be 87754.5576, so I'd expect the rounded value to be either
> 87754 or 87755. However, it's 87753! [0] I think this may be caused by
> using "floor" for the hours and minutes, in combination with the fractional
> frame rate.
>
>
23.976 is the rounded form of 24000/1001, which is the more typical value.
In any case, from here you can see unit tests that exercise this:

https://github.com/mltframework/mlt/blob/master/src/tests/test_properties/test_properties.cpp#L188

A few of these cycle through 999 frames (over 11 hours at 240 fps) at
some common frame rates to ensure that when you convert from frame number
to a clock time value and back that you get the same frame number. But I do
not think every frame rate is going to work with the limited precision of
milliseconds.


>   - It seems `lrint` determines its rounding direction depending on values
> in the current environment. That seems to mean a user can also lose sample
> accuracy if, for example, `lrint` rounds one way on my machine and then a
> friend reads my .mlt file with a different rounding direction. Is this true?
>
>
Not to my understanding. The rounding mode can be set programmatically
using fesetround() where the "e" refers to an "environment" in the
documentation, but that is not the same thing as an environment variable.
It refers to the process runtime state and mentions no environment
variables. MLT does not call this, and while it is possible an application
has that seems rather rare.


Thanks,
> Tom
>
> [0] My code:
>
> #include 
> #include 
>
> void main(void) {
>double fps = 23.976;
>int hours = 1;
>int minutes = 1;
>double seconds = 0.1;
>printf("%f\n", floor( fps * hours * 3600 ) + floor( fps * minutes * 60
> ) + lrint( fps * seconds ));
> }
>
>
> On Sat, Aug 21, 2021 at 02:25:43AM +, Brian Matherly wrote:
> >  > Am I correct that MLT translates from these clock times to frame
> numbers and uses frame numbers for everything internally?
> > Yes. "frame number" is often referred to as "position" in the code. I
> think the two terms are used interchangably.
> > >  How does rounding work?
> > The code is here:
> https://github.com/mltframework/mlt/blob/master/src/framework/mlt_property.c#L371
> > It uses lrint() for rounding the seconds part.
> > ~Brian
> >
> > On Thursday, August 19, 2021, 11:45:00 PM CDT, amindfv--- via
> Mlt-devel  wrote:
> >
> >  From reading the "time properties" doc (
> https://www.mltframework.org/blog/time_properties), it seems any number
> with a radix is interpreted as a clock time - e.g. "00:00:00.5" means half
> a second.
> >
> > A couple questions:
> >
> >   - Am I correct that MLT translates from these clock times to frame
> numbers and uses frame numbers for everything internally?
> >   - How does rounding work? If I'm working at 24fps, frame number 8 has
> clock time 0.... and frame 9 has clock time 0.375. If I say
> "00:00:00.334", is that identical to saying "00:00:00.374"? And thus
> "00:00:00.333" would refer to the earlier frame 7? (I.e. the frame number
> is always rounded down?) Or is there some other simple and consistent
> translation from these clock times to frame numbers?
> >
> > 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

Re: [Mlt-devel] It's hard to work without information

[Dan Dennedy]

On Mon, Aug 16, 2021 at 6:38 AM Spielmops  wrote:

> I want to use an audio-filter with Kdenlive. So I put the treble-filter
> onto my audio and see the effects parameter. No clue, what these parameters
> want. A frequency-parameter "a.frequency" with a range up to 1 Mio.? And
> another one "a.f" with the same range? I try to gather information.
>

I do not use or develop Kdenlive. I figured out that "Mio" is German for
"million," and I suspect it is somehow based on the maximum reported here:
https://mltframework.org/plugins/FilterAvfilter-treble/
That comes from FFmpeg/libavformat's treble filter. MLT provides bridges to
many other libraries in addition to some of its own effects. That is the
limit as reported by the library.


> I call
> https://www.mltframework.org/plugins/PluginsFilters/
>
> I find the filter "sox.treble", click on it and get:
> https://www.mltframework.org/plugins/FilterSox-treble/
>
> At the bottom there is the line, I#m looking for: the parameters. I click
> onto this lik and get:
> - 404 File not found
>

I fixed this broken link. The docs are generated into markdown and then
into HTML. This parameter value unexpectedly included a markdown character
sequence to denote a link, and I had to escape it in the docs generator.


>
> Where to look now? It's a SoX-filter, so I look for SoX:
> http://sox.sourceforge.net/sox.html
>
> Now, that should it be. I look for treble and get a description but no
> parameters. But a line that gives me hope:
> - The filters are described in detail in [1].
>
> Ok, I goto [1] and read:
> - [1] R. Bristow-Johnson, Cookbook formulae for audio EQ biquad filter
> coefficients, http://musicdsp.org/files/Audio-EQ-Cookbook.txt
>
> So, now the last step, I call
> http://musicdsp.org/files/Audio-EQ-Cookbook.txt
>
> And get:
>
>  SORRY/
>  \ /
>   \This page does /
>]   not exist yet.
>
>
We are not responsible for SoX's docs, and again MLT is reporting what the
library is giving us.


> How would you proceed?
>
>
SoX is primarily a command line tool where the typical source of
documentation is the `man` command. Doing a Google search on "man sox"
revelead this page that explains a lot about this effect's parameters:
http://sox.sourceforge.net/sox.html#EFFECTS

MLT is primarily a developer tool. I recommend that you help Kdenlive
improve its UIs and docs in this area. MLT is not going to manually tweak
the information coming from the other libraries. Generating things like
these docs and parameters make sense for our very small developer project,
but that approach may not make as much sense for an end user-facing tool
such as Kdenlive.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Python bindings and filters.

[Dan Dennedy]

On Sun, Aug 15, 2021 at 3:05 PM Andre Caldas 
wrote:

> Hello!
>
> I was writing a frei0r mixer2. I did it, but then I realized that it
> would be better if I wrote a native MLT filter. If possible, I would
> like to write it in python.
>
> So, I would like to ask a question!
> - Can I use python bindings to write an MLT filter in python?
>
>
I do not think it is possible with the current bindings. Even if you were
to extend it and make it possible, I will not accept it for a merge into
the official repository.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] DTD: add properties to entries?

[Dan Dennedy]

On Sun, Aug 15, 2021 at 1:02 PM amindfv--- via Mlt-devel <
mlt-devel@lists.sourceforge.net> wrote:

> More recent versions of Kdenlive are putting properties in entries. For
> example:
>
> 
>  2
> 
>
>
> and:
>
> 
>  2
>  1
>  
>  ...
>
> This technically isn't part of the spec (at least according to
> src/modules/xml/mlt-xml.dtd). Would there be any downside to changing the
> MLT XML DTD from...:
>
>  transition | chain)* >
>
> ...to:
>
>  | filter | transition | chain)*) >
>
>
>
I do not see any downside, but I have not tested that property as a child
of entry works. Assuming it works because it is working in a
Kdenlve release (and not simply a bug in development code), please go ahead
and submit a pull request. Thanks
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] How to register a frei0r plugin.

[Dan Dennedy]

On Sat, Aug 14, 2021 at 11:24 AM Andre Caldas 
wrote:

> Dear developers,
>
> I have written a frei0r plugin. It is a frei0r::mixer2 class. I have
> compiled it and produced a ".so" file.
>
> How do I register it (locally: ~/.local/share/...) with MLT?
>
>


You need to install the so to an expected directory per the frei0r
specification such as /usr/lib/frei0r-1


> Cheers,
> André Caldas
> --
> - Por que altera a ordem natural da conversação!
> - Por que não?
> - Eu não gosto, não.
> - Você gosta quando copiam a mensagem original ao final do e-mail?
>
>
> ___
> 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] Future of higher bit depth/dynamic range/etc

[Dan Dennedy]

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

Re: [Mlt-devel] Playing remote files is broken and crashes

[Dan Dennedy]

Thanks JB, you are correct! I will make a v6.26.1 release for this.


On Tue, Apr 13, 2021 at 9:23 AM Jean-Baptiste Mardelle 
wrote:

> Hi all,
>
> I just wanted to let you know I just discovered that playing remote files
> does
> not work anymore with MLT and results in a crash, due to this commit:
>
> https://github.com/mltframework/mlt/commit/
> d769db2427823f65cba4e097b7fef8a5a8a77469#diff-
> dd4dd7f8b6c28984ac8e670241eb3a0e5ddc65efa5c2784a7267a018d6ff6811
>
> To reproduce:
> melt http://techslides.com/demos/sample-videos/small.mp4
> Crashes with MLT 6.26
>
> The below patch (restoring the avio_check) fixes the problem and crash,
> above
> line correctly plays the video, but not sure it's wanted or the best way.
> Anyways, we should at least try to fix the crash.
>
> Best regards,
> Jean-Baptiste
>
> diff --git a/src/modules/avformat/producer_avformat.c
> b/src/modules/avformat/
> producer_avformat.c
> index 6628978f..d5869fed 100644
> --- a/src/modules/avformat/producer_avformat.c
> +++ b/src/modules/avformat/producer_avformat.c
> @@ -544,7 +544,7 @@ static char* parse_url( mlt_profile profile, const
> char*
> URL, AVInputFormat **fo
> char *url = strchr( protocol, ':' );
>
> // Truncate protocol string
> -   if (url && url - protocol > 1) { // if defined and not a drive
> letter
> +   if (url && url - protocol > 1 && avio_check( URL, 0 ) < 0) { // if
> defined and not a drive letter
> url[0] = '\0';
> ++url;
> mlt_log_debug( NULL, "%s: protocol=%s resource=%s\n",
> __FUNCTION__, protocol, url );
>
>
>
>
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

[Mlt-devel] MLT v6.26.0 release soon

[Dan Dennedy]

I plan to release the next version of MLT this weekend April 10 or 11.
This is the last planned release of major version 6. After that I will
make a v6 branch and merge the v7 branch into master. We can still
make another v6 release if something critical is needed. Just a head's
up.


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

[Mlt-devel] MLT version 7 plans

[Dan Dennedy]

Brian has been working on time effects (i.e. keyframes for speed and
direction) for a good while now, and a couple of months ago I realized it
requires breaking the API. So, if we are going to break the API I want to
make some other changes we can live with for a little while. However,
considering how long he has worked on this, I do not want it to take too
long or be too adventurous. Mostly, we are talking about removing
deprecated and legacy things, and a little renaming. Our goal is to make
the first release by the end of April. There will be a 6.26.0 release
before it, soon.

The branch in git is named "v7".

The plans are on the Road Map page (that also includes things beyond the
first 7.0 release):
https://mltframework.org/changes/todo/

I started working on a migration guide for app developers:
https://mltframework.org/docs/v7migration/

And here is a GitHub for tracking our tasks:
https://github.com/mltframework/mlt/issues/655

My changes in mlt_events and a LADSPA-only build option for the jackrack
module were motivated by my port to macOS on Apple M1 silicon (still in
progress).

In particular, I want you to see the proposed removal of the motion_est
module with its autotrack_rectangle filter, and the region filters in the
core module.

I think the autotrack_rectangle is sub-par compared to opencv.tracker, but
I do not have much experience with either. In any case, the only other
interesting thing in motion_est is slowmotion, which is unsatisfactory. And
I would rather not bother to port this module's usage of mlt_geoemtry to
mlt_rect.

Removal of the region filter and transition is due to its usage of the
mlt_frame.get_alpha_mask function pointer I want to remove to simplify
handling of alpha channel. Besides, we now have mask_start and mask_apply
which are more flexible in some ways; you can see how they are used in
Shotcut. You can use any filter in conjunction with mask_start but
typically something that affects alpha. Then, any number of other filters
including additional alpha-affecting ones before mask_apply, which
composites the result onto the snapshot made by mask_start. (These are not
new to v7.) Not yet implemented is multiple instances of mask_start and
mask_apply on the same producer.

Please let me know about any show-stoppers or objections with these plans.
Sincerely,
Dan
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Problem with crop

[Dan Dennedy]

melt and the xml module require using the loader producer. The loader
producer is very special and chooses which real producer to use based on
the resource string - configured in  loader.dict - as well as adding what
we call normalization (aka conform) filters - configured in loader.ini.
Extremely important filters that loader adds that are not in loader.ini are
image and audio converters to convert image and audio data between services
as needed. However, the API lets you easily bypass this loader producer
when you explicitly pass the name of the service as an argument to the
corresponding factory function. If you do not use loader, then you really
ought to add the conversion filters manually to each producer.

See mlt_factory_producer() in
https://www.mltframework.org/doxygen/mlt__factory_8c.html#a093871823fdf4dad4aee091e98832586

It says "service" is optional and to see about MLT_PRODUCER. Not mentioned
is that this is an environment variable. It is documented under "Related
Pages" of Doxygen docs:
https://www.mltframework.org/doxygen/envvars.html

And then here is docs about loader producer:
https://mltframework.org/plugins/ProducerLoader/

Basically, if you want full control as you have done, then you will not be
able to use MLT XML and melt. Sorry, but I will not make changes to make
these to work without the loader producer. You can set the environment
variable MLT_PRODUCER to empty but then xml and melt are essentially
broken. The concept of the loader producer is so heavily integrated into
how all of the mature, established video editors and melt use MLT that I am
unwilling to risk the change. It also goes without saying that MLT is
really only ever used and tested using the loader producer. If you want to
continue to not use the loader producer, then you must create your own way
to serialize, deserialize, and render.

For the crop filter, this is a source image crop and, by design, must come
before all other filters including the ones that loader adds to
deinterlace, scale, and pad to conform the source to the mlt_profile. The
second instance of the crop filter then provides only the parameters to the
one previously added by loader. There is also a qtcrop filter that fills
the area outside of a shape with a color including alpha.


On Sun, Jan 31, 2021 at 1:39 PM linux...@tin.it  wrote:

> Hi all,
>
> I am writing a video editor using mlt. The editor basically
> edits a playlist, inserts filters, and does preview via a swallowed SDL
> window. When requested, the editor generates an XML file to be fed to
> melt(1). So far so good.
>
> In order to crop clips, I used until now the
> stock "crop" filter; it works well but, in the editor, I have to put
> two instances of it, otherwise the crop is not performed. So, I wrote
> my own crop filter, which crops in-place instead of setting some
> properties and letting another instance of itself to do the work. The
> filter works well when used in the editor ("internal instance") but,
> when used by melt(1), the result is wrong. I am sure my filter does the
> correct job, but it seems the image it receives, to be cropped, gets
> scaled down, even if width and height are correct.
>
> For example, I take
> a 320x240 clip and crop 160 pixels from left. In the editor, the result
> is a 160x240 picture - correct. When using melt, the output written in
> the file (consumer avformat) is correctly 160x240, but the contents are
> the wanted picture 80 pixels wide, padded to the right with 80 blank
> pixels.
>
> It is about a week I am trying to solve. I tried to set frame
> properties in the filter, "resize_width", "resize_height", with all the
> possible values, before and after the cropping - nothing happens, the
> result is always the same.
>
> Then I ran melt with -debug, and saw that a
> swscale filter kicks in and resizes 320 -> 160. Of course, no resizing
> should be done, and in fact this does not happen when I am using my
> interactive editor. Still this does not explain why the final image is
> blank-padded on the right, maybe another unwanted filter kicks in.
>
> My
> question is: why melt uses somewhere a rescale filter, when nobody
> asked for it? How can I just take the original frame, crop/resize it at
> will, and pass it to the consumer (or other filters)? When the
> "pipeline" is constructed in the editor it works well, apparently melt
> does something under the hood which I need to exclude. What should I do
> to make melt replicate the same behavior of the interactive editor?
>
>
> Regards,
> linuxfan
>
>
>
>
>
> ___
> 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] Some issues with the strobe filter

[Dan Dennedy]

On Mon, Jan 11, 2021 at 3:27 PM jb  wrote:

> Hi all,
>
> The strobe filter, recently added, seems to have a few issues, that I'd
> like to bring up so that we can either fix or blacklist it in Kdenlive:
>
> 1- It does not explicitly ask for the mlt_image_rgb24a image format, but
> only processes  if the frame has this format. Is this the wanted behavior ?
> It might be confusing to the user as the filter only operates on some file
> formats and not some others...
>
>
That is not a problem. This is not the only filter that operates in more
than one image format. Compatibility with more image formats rather than
less is a good thing. It should not only operate on some file formats; it
depends more on what format is requested based on what you are doing with
the alpha channel.


> 2- It crashes trying to access invalid memory at line 80:
>
> image[i] = 0;
>
> If it helps, I have a patch proposal that fixes both issues for me:
>
>
> https://github.com/j-b-m/mlt/commit/c4ae4796f72a150a49cfa740c479a755c5f54d8b
>
>
I fail to see how your patch improves the second point since they both
assume the image pointer is not NULL and that width and height are correct.
Maybe you can improve your points. I find rewriting the for loop to be less
informative than a more direct fix. In any case, please address the author
of this filter in your e-mail because he might not be using the mailing
list.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] future of frame-threading in MLT

[Dan Dennedy]

On Tue, Dec 8, 2020 at 7:14 PM Brian Matherly 
wrote:

>
> > As a reminder, frame threading is when
> > abs(consumer.get_int("real_time")) > 1. There are some problems with it.
> > 1. sometimes there is a crash
> > 2. image artifacts due to race conditions
>
> I think that the main reason for this is that we try to allow each
> service instance to be running get_image() in multiple threads at the
> same time.
>
> I would suggest the following strategy:
>
> 1) Design each service to use a lock (mutex) around the entire
> get_image() function. I think this would solve most crash and artifact
> issues. It would also simplify the code design in some cases.
>
>
I think that would help a lot for those 2 issues, but it will sacrifice a
lot of parallelism. Take a simple use case of scaling a video. Today, with
frame threading, it can be scaling multiple frames in parallel. With your
proposal it would not. Only different operations that are not waiting on a
common operation would be in parallel.


> 2) Optimize each service so that the get_image() function can complete
> in one frame duration. For 60fps, that would be 16ms. This optimization


Of course, that is a nice goal, but you know it is not possible for all
workloads when you do not control the hardware. A budget laptop CPU is
simply not going to be able to handle 4K60 in real time on most operations.

can be done using OpenMP, SMID or slice threading - which ever is the
> best solution for each particular situation.
>
> 3) Set the frame threading count to whatever is needed to overcome the
> delay through the stackup of services. For example, if there are 3
> filters and one transition, then use 4 frame threads for real-time
> performance.
>
>
This can change per frame, but this is probably the least important of your
points.


> > 3. slowness due to accessing slow-to-seek sources in non-sequential order
>
> With my proposal above, I think we could serialize the access to the
> producer. As long as the image can be produced within one frame duration
> (on average). When the consumer is assigning threads, it would need some
> way to wait until the producer from the previous frame has provided an
> image. This would add one additional frame thread to the stackup above.
>
>
Perhaps, but it seems like even more work than what I suggested may already
be too much to invest into an 8-bit pipeline!

> 4. inefficient usage of CPU cache memory
> > 5. increased memory usage
> >
> > #1 and 2 have improved significantly over the years through diligence
> > and hard work, but it still occurs sometimes because the framework
> > permits so many combinations of things. I think the most recent move
> > to use thread-local frei0r instances (context) helped, but that also
> > adds some inefficiency.
> >
> > For #1, in Shotcut, if an export job with frame-threading fails,
> > Shotcut automatically restarts the job without frame-threading. And
> > for all of the above reasons, Shotcut no longer defaults to enable
> > frame-threading. I should also point out that due to the
> > inefficiencies, Shotcut also limits the amount of threads to 4 (and
> > automatically computes a lower amount on systems with <= 4 CPU threads).
> >
> > There is no solution today for #3. In the avformat producer, we could
> > cache decoded frames such that an out-of-order frame request will get
> > a decoded frame. Today, the producer caches converted video frames.
> > Converted frames are frames that have been converted their pixel
> > format and colorspace to something available in MLT based upon the
> > get_image request such that requesting the same frame requires no
> > re-conversion. I do not want to cache both because that is memory
> > hungry. I do not want to convert every decoded frame to reach the
> > requested frame because that will make it slower. I might convert this
> > to cache unconverted decoded frames.
> >
> > #4 and #5 rather come with the territory especially #5 when frames
> > hold a whole uncompressed image.
> >
> > I want to expand the usage of slice threading. I have a branch ready
> > to merge that improves mlt_slices in frei0r, but you still need to opt
> > into it on a per-plugin basis since some of them are incompatible.
> > Basically, this simple change automatically adjusts the number of
> > slices until each slice has the same height.
> >
> > I think it will be easy to add slice processing to all cases of pixel
> > format and colorspace conversion using swscale as proven by the
> > existing code for mlt_image_yuv422 in the avformat producer.
> > Slice-based scaling is still not reliable in swscale, and I might add
> > a z.img scaler, which supports tiles.
> >
> I have also wondered if we could simply reduce the number of conversions
> in the stackup by strategically adding more pixel format support to a
> few specific filters for common use cases. Maybe worth some investigation.
>

That can help too.


>
> > Of course, there are still more places in MLT where one can 

[Mlt-devel] future of frame-threading in MLT

[Dan Dennedy]

In a pull request, Vincent raised an interesting point regarding
frame-threading in MLT:
https://github.com/mltframework/mlt/pull/621#issuecomment-741087704

As a reminder, frame threading is when abs(consumer.get_int("real_time")) >
1. There are some problems with it.
1. sometimes there is a crash
2. image artifacts due to race conditions
3. slowness due to accessing slow-to-seek sources in non-sequential order
4. inefficient usage of CPU cache memory
5. increased memory usage

#1 and 2 have improved significantly over the years through diligence and
hard work, but it still occurs sometimes because the framework permits so
many combinations of things. I think the most recent move to use
thread-local frei0r instances (context) helped, but that also adds some
inefficiency.

For #1, in Shotcut, if an export job with frame-threading fails, Shotcut
automatically restarts the job without frame-threading. And for all of the
above reasons, Shotcut no longer defaults to enable frame-threading. I
should also point out that due to the inefficiencies, Shotcut also limits
the amount of threads to 4 (and automatically computes a lower amount on
systems with <= 4 CPU threads).

There is no solution today for #3. In the avformat producer, we could cache
decoded frames such that an out-of-order frame request will get a decoded
frame. Today, the producer caches converted video frames. Converted frames
are frames that have been converted their pixel format and colorspace to
something available in MLT based upon the get_image request such that
requesting the same frame requires no re-conversion. I do not want to cache
both because that is memory hungry. I do not want to convert every decoded
frame to reach the requested frame because that will make it slower. I
might convert this to cache unconverted decoded frames.

#4 and #5 rather come with the territory especially #5 when frames hold a
whole uncompressed image.

I want to expand the usage of slice threading. I have a branch ready to
merge that improves mlt_slices in frei0r, but you still need to opt into it
on a per-plugin basis since some of them are incompatible. Basically, this
simple change automatically adjusts the number of slices until each slice
has the same height.

I think it will be easy to add slice processing to all cases of pixel
format and colorspace conversion using swscale as proven by the existing
code for mlt_image_yuv422 in the avformat producer. Slice-based scaling is
still not reliable in swscale, and I might add a z.img scaler, which
supports tiles.

Of course, there are still more places in MLT where one can apply
mlt_slices and convert floating point code to integer. And both frei0r and
MLT can use OpenMP and more SIMD. But all that for an 8-bit pipeline? I am
not so sure.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] mlt api changed in 6.22?

[Dan Dennedy]

On Tue, Nov 10, 2020 at 4:41 PM Rafał Lalik  wrote:

> Hi,
>
> somewhere around mlt-6.6 (3y ago) I developed my custom effect for
> typewriting
> which I use with kdenlive. Last time I used it in September I think and it
> worked fine, but now, having mlt-6.22 it does not work anymore.
>
> So I made some checks in the filter_x_init of my effect I add some
> printf
> command to report execution, and to have control sample, I added similar
> check
> in the oldfilm/vigniette effect from mlt sources.
>
> Apparently, when my clip in kdenlive is loaded, I see only report from
> oldfilm/vigniette effect and not from my custom effect.
>
> So my question would be - was there any change in mlt-6.22 (or 6.20 as I
> do not
> remember which version I had back in September) which could influence
> initializing of the effect?
>
>
Nothing changed in module registration. Your module .so file needs to be in
the correct folder. A better way to check if the module is available at the
command line is with `melt -query`. MLT locates modules based on the build
prefix e.g. $PREFIX/lib/mlt or environment variable MLT_REPOSITORY. If you
are trying to see it in Kdenlive, maybe it depends on something being
Kdenlive or the module's yml file also installed.

And quick info how I designed my effect.
>
> I took sources of mlt, get rid of all code, created my own src/module/rl
> directory and adjusted original Makefile to the new source tree. And as I
> said,
> it worked for over 3 years from version 6.6 until 6.20?
>
> The source is available here:
> https://github.com/rlalik/mlt_extra_modules
>
> I would appreciate any advice which helps me fix the problem.
>
> I see your service depends on kdenlivetitle producer and the producer
setting a property "producer_kdenlivetitle" on the frame. I can confirm
that still exists.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] How to view simultaneously unprocessed frames and processed ones in two X windows?

[Dan Dennedy]

On Fri, Oct 9, 2020 at 10:19 PM linux...@tin.it  wrote:

> Hi all. I am writing a basic video editor based on MLT. At the moment,
>
> I use an mlt_playlist, which lets me append video files, break them in
> clips, and connect different filters to different clips. So far so
> good, I appreciate
> the clean C interface of MLT: congratulations. But
> now I'm facing a problem
> I don't know how to manage. In my editor, I
> would like to always see two
> pictures, the original one and the
> manipulated one. I thought I could use
> a "multi" consumer, but this
>

That will not work. MLT does not have a general tee-like component. The
consumer always goes at the "end" of the pipeline or graph like a sink.
multi consumer was designed primarily for use with the avformat consumer to
provide different renderings/encodings of the same composition.


> multi consumer should not be attached to the playlist itself because, I
> suppose, the playlist spits out frames already processed by the
> different filters attached to the single clips.
>
> Perhaps I should
> attach a multi consumer to *every* clip I append in the playlist?
>

That is not how a consumer is used. MLT does not well support arbitrarily
combining things in weird combinations. There are tried and true patterns
exercised and tested by the demo scripts, melt command line, and the 3
popular open source video editors that use MLT.


> Could
> it work? Then every clip would have a multi consumer which would
>
> duplicate the frames: one leg would go to the subsequent filter chain,
> and
> the other leg would send unprocessed frames to my "original clip"
> window.
>
> Or is there another way, more simple?
>
>
I have never tried to do what you are doing, but I think you are going to
have to compose and run distinct graphs: one that is unfiltered and another
that is filtered and attach a consumer to each. Alternatively, you could
write a new filter that stores a snapshot of the frame's current image to
some unique property. Add this filter before all other filters. Then, when
the consumer emits a frame-displayed event, get this snapshot image from
the frame to display in another window.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] XML DTD tweak?

[Dan Dennedy]

On Fri, Oct 9, 2020 at 5:22 PM amindfv--- via Mlt-devel <
mlt-devel@lists.sourceforge.net> wrote:

> In src/modules/xml/mlt-xml.dtd, playlists are described as having at least
> 1 item in them (because of the '+' at the end):
>
>  tractor | multitrack)+) >
>
> However, by default kdenlive generates empty tracks, creating technically
> non-standard XML, e.g.:
>
> 
>  1
>  Audio 2
> 
> 
>  1
>  Audio 1
> 
> 
>  Video 1
> 
>
> Any objections to changing the '+' to a '*' on this line of the DTD, thus
> supporting empty playlists?
>

No objection. Please submit pull request.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] avformat consumer duplicating last frame

[Dan Dennedy]

On Tue, Oct 6, 2020 at 1:15 AM jb  wrote:

> Hi all,
>
>
> While working on a Kdenlive rendering issue, I noticed that the avformat
> consumer duplicates the last frame on encoding. So the resulting file is
> 1 frame longer than wanted.
>
> This is easily reproducible with:
>
> melt color:red out=10 -consumer avformat:red.mp4
>
> This produces a 12 frames video, instead of 11 (0 - 10 range).
>
> You can notice the frame duplication using the count producer:
>
> melt count style=frames out=10 -consumer avformat:count.mp4
>
> Results in a 12 frames long video with last video frame repeated twice.
>
>
This is true for _some_ codecs. With `avformat:count.dv` it does not. With
`avformat:count.mp4 acodec=ac3` or `acodec=mp2` it does not.


>
> After some tests, I can give the following details:
>
> This only happens when encoding audio, so is related to the handling of
> audio data.
>
> rendering with an=1 (to disable audio) gives a correct length file.
>
>
I think it is definitely related to whether the audio codec has delay (see
"General capabilities" in `ffmpeg -h encoder=aac` output). But also some
codecs impose framing of data. For example AAC frames hold 1024 samples.
When you look at the `ffprobe -show_streams -pretty` output of count.mp4
with aac, it shows the video stream duration=0:00:00.44 and the audio
stream duration duration=0:00:00.448000 - a difference of 8 ms whereas the
video frame duration of this 25 fps file is 40 ms.


> After more tests, I traced back the regressions to this commit (1) from
> may 2018 (!), switching to the newer FFmpeg api using
> avcodec_send_frame()/avcodec_receive_packet.
>
> Commenting out the code flushing audio data :
>
>
> https://github.com/mltframework/mlt/blob/master/src/modules/avformat/consumer_avformat.c#L2184
>
> Seems to fixes the problem, but I am not sure it's the correct solution.
>

It definitely is not, and I do not believe there is a correct solution.
`ffmpeg -i count.dv count-ffmpeg.mp4` also shows a duration of 12 frames in
MLT. In ffprobe output, the duration of the audio in count-ffmpeg.mp4
matches its video, but the nb_frames fields for both files match: 11 for
video and 22 for audio.

If you try to add an option to skip flushing the audio or add a heuristic
to drop a small amount of extra samples at then end, I guarantee eventually
you will get a bug report about discarding data. Maybe someone wants to
compare the avformat consumer flushing code with that of ffmpeg's. Maybe
some conditions need to be added or flags passed to some call. I am not
volunteering as I have other higher priorities.


> So if anyone has a hint on how to correctly fix this, help is welcome.
>
> Best regards,
>
> Jean-Baptiste
>
>
> (1)
>
> https://github.com/mltframework/mlt/commit/1937704936a6569f181b7295fb8bafd223d13d66#diff-1bba886ccf70d0171adb4e7842ec3d58
>
>
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

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

[Dan Dennedy]

On Sun, Sep 13, 2020 at 9:00 AM amin...@mailbox.org 
wrote:

> > On Thu, Jul 30, 2020 at 3:09 PM Tom Murphy  wrote:
> >
> > > > 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
> > >
> >
> > Correct. Brian meant it should support it as an input and decode it
> > correctly, but it will be conformed to one of the image formats supported
> > by the services. The mlt_image_yuv422p16 he mentions only works for
> > decklink producer to avformat consumer currently. It also possible to
> > convert 10-bit YUV to 8-bit full range sRGB, which most effects support,
> > convert to 10-bit YUV, and encode as 10-bit. I think Brian was also
> talking
> > a bit technical about what can be possible with small changes if you are
> a
> > developer. Currently, the avformat producer (decoder) does not output to
> > mlt_image_yuv422p16, and I doubtful that is going to be the preferred
> image
> > format for a future processing pipeline that supports 10-bit end-to-end.
>
> Is my intuition correct that (e.g.) 10-bit yuv420 needs to be supported on
> a per-service basis?
>
> So if I have 10-bit color producers and no filters or transitions, then
> "all" I need is for the avformat consumer to support 10-bit color in order
> to prevent loss of image quality?
>
>
The consumer already supports mlt_image_yuv422p16 but not the avformat
producer.


> And then, if I have the same setup as above but I add one filter (or
> transition), then I just need that particular filter or transition to
> support 10-bit color?
>


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.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Fwd: Bug#967633: mlt: depends on deprecated GTK 2

[Dan Dennedy]

On Tue, Aug 4, 2020 at 9:12 AM Patrick Matthäi 
wrote:

> Hi Dan,
>
> any doubts about deactivating gtk2? It is also marked as deprecated
> (src/modules/gtk2/deprecated)
>

Deprecation is deactivation in the MLT configure script. For the latest
release you must remove that file to activate that module.


>  Weitergeleitete Nachricht 
> Betreff: Bug#967633: mlt: depends on deprecated GTK 2
> Weitersenden-Datum: Tue, 04 Aug 2020 10:59:05 +
> Weitersenden-Von: s...@debian.org
> Weitersenden-An: Patrick Matthäi 
> 
> Datum: Tue, 04 Aug 2020 11:55:15 +0100
> Von: s...@debian.org
> Antwort an: s...@debian.org, 967633-mainto...@bugs.debian.org
> An: mainto...@bugs.debian.org
>
> Source: mlt
> Severity: normal
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: gtk2 oldlibs
> Control: block 947713 by -1
>
> This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
> binary packages with a Depends on GTK 2.
>
> GTK 2 was superseded by GTK 3 in 2011 (see
>  ). It no
> longer receives any significant
> upstream maintenance, and in particular does not get feature development
> for new features like UI scaling on high-pixel-density displays (HiDPI)
> and native Wayland support. GTK 3 is in maintenance mode and GTK 4 is
> approaching release, so it seems like a good time to be thinking about
> minimizing the amount of GTK 2 in the archive.
>
> GTK 2 is used by some important productivity applications like GIMP, and
> has also historically been a popular UI toolkit for proprietary software
> that we can't change, so perhaps removing GTK 2 from Debian will never be
> feasible. However, it has reached the point where a dependency on it is
> a bug - not a release-critical bug, and not a bug that can necessarily
> be fixed quickly, but a piece of technical debt that maintainers should
> be aware of.
>
> A porting guide is provided in the GTK 3 documentation:
> https://developer.gnome.org/gtk3/stable/migrating.html
>
> Some libraries (for example libgtkspell0) expose GTK as part of their
> API/ABI, in which case removing the deprecated dependency requires
> breaking API/ABI. For these libraries, in many cases there will already
> be a corresponding GTK 3 version (for example libgtkspell3-3-0), in which
> case the GTK 2-based library should probably be deprecated or removed
> itself. If there is no GTK 3 equivalent, of a GTK 2-based library,
> maintainers should talk to the dependent library's upstream developers
> about whether the dependent library should break API/ABI and switch
> to GTK 3, or whether the dependent library should itself be deprecated
> or removed.
>
> A few packages extend GTK 2 by providing plugins (theme engines, input
> methods, etc.) or themes, for example ibus and mate-themes. If these
> packages deliberately support GTK 2 even though it is deprecated, and
> they also support GTK 3, then it is appropriate to mark this mass-filed
> bug as wontfix for now. I have tried to exclude these packages from
> the mass-bug-filing, but I probably missed some of them.
>
> Regards,
> smcv
>
> ___
> 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] 10-bit color?

[Dan Dennedy]

On Thu, Jul 30, 2020 at 3:09 PM Tom Murphy  wrote:

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

Correct. Brian meant it should support it as an input and decode it
correctly, but it will be conformed to one of the image formats supported
by the services. The mlt_image_yuv422p16 he mentions only works for
decklink producer to avformat consumer currently. It also possible to
convert 10-bit YUV to 8-bit full range sRGB, which most effects support,
convert to 10-bit YUV, and encode as 10-bit. I think Brian was also talking
a bit technical about what can be possible with small changes if you are a
developer. Currently, the avformat producer (decoder) does not output to
mlt_image_yuv422p16, and I doubtful that is going to be the preferred image
format for a future processing pipeline that supports 10-bit end-to-end.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Mlt::Properties pass_list not triggering property-changed

[Dan Dennedy]

On Mon, Jul 27, 2020 at 6:15 PM Dan Dennedy  wrote:

> JB, I want to revert your change here temporarily and make a release. It
> is time to make a new release, but this change is too fundamental to
> include in a release right now. Then, I would restore the change after
> release. Do you agree?
>
>
I did not get an answer, so I went ahead and reverted. After a successful
nightly build, I will make the next release by the end of July and restore
your change.


>
> On Fri, Jul 24, 2020 at 7:48 PM Dan Dennedy  wrote:
>
>> On Fri, Jul 24, 2020 at 1:36 PM jb  wrote:
>>
>>> Hi all,
>>>
>>> Looking at a timewarp producer issue in Kdenlive, I noticed that the MLT
>>> properties method "mlt_properties_pass_list" does not trigger a
>>> "property-
>>> changed" event.
>>>
>>> In Kdenlive, we use this "mlt_properties_pass_list" method to pass some
>>> properties on the producer. However, since the "property-changed" event
>>> is not
>>> triggered, the properties are not applied on the Timewarp producer that
>>> applies changes to the original avformat producer on the
>>> "property-changed"
>>> event.
>>>
>>> Is there any reason to not trigger a property-changed event in
>>> mlt_properties_pass_list ?
>>>
>>
>> I do not recall there being a reason to not fire this event, and I do not
>> see anything in git log on this file about removing it. It is most likely
>> an oversight in the contributor's submission and review. As you can see
>> from the code comment and git blame it came from an infrequent contributor.
>> We can add this change and then if something is negatively affected try
>> blocking events in that area.
>>
>>
>>>
>>> If this is meant to be, I can change Kdenlive to use a property set
>>> method,
>>> but otherwise, it seems reasonable to fix it with this 1 line patch :
>>>
>>> 
>>>
>>> diff --git a/src/framework/mlt_properties.c
>>> b/src/framework/mlt_properties.c
>>> index 94afe45f..f3e419b5 100644
>>> --- a/src/framework/mlt_properties.c
>>> +++ b/src/framework/mlt_properties.c
>>> @@ -614,6 +614,7 @@ void mlt_properties_pass_property( mlt_properties
>>> self,
>>> mlt_properties that, con
>>> return;
>>>
>>> mlt_property_pass( mlt_properties_fetch( self, name ), that_prop
>>> );
>>> +   mlt_events_fire( self, "property-changed", name, NULL );
>>>  }
>>>
>>>  /** Copy all properties specified in a comma-separated list to another
>>> properties list.
>>>
>>> 
>>>
>>> Thanks in advance for your opinion on this.
>>>
>>> Regards,
>>> Jean-Baptiste
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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] Mlt::Properties pass_list not triggering property-changed

[Dan Dennedy]

JB, I want to revert your change here temporarily and make a release. It is
time to make a new release, but this change is too fundamental to include
in a release right now. Then, I would restore the change after release. Do
you agree?


On Fri, Jul 24, 2020 at 7:48 PM Dan Dennedy  wrote:

> On Fri, Jul 24, 2020 at 1:36 PM jb  wrote:
>
>> Hi all,
>>
>> Looking at a timewarp producer issue in Kdenlive, I noticed that the MLT
>> properties method "mlt_properties_pass_list" does not trigger a "property-
>> changed" event.
>>
>> In Kdenlive, we use this "mlt_properties_pass_list" method to pass some
>> properties on the producer. However, since the "property-changed" event
>> is not
>> triggered, the properties are not applied on the Timewarp producer that
>> applies changes to the original avformat producer on the
>> "property-changed"
>> event.
>>
>> Is there any reason to not trigger a property-changed event in
>> mlt_properties_pass_list ?
>>
>
> I do not recall there being a reason to not fire this event, and I do not
> see anything in git log on this file about removing it. It is most likely
> an oversight in the contributor's submission and review. As you can see
> from the code comment and git blame it came from an infrequent contributor.
> We can add this change and then if something is negatively affected try
> blocking events in that area.
>
>
>>
>> If this is meant to be, I can change Kdenlive to use a property set
>> method,
>> but otherwise, it seems reasonable to fix it with this 1 line patch :
>>
>> 
>>
>> diff --git a/src/framework/mlt_properties.c
>> b/src/framework/mlt_properties.c
>> index 94afe45f..f3e419b5 100644
>> --- a/src/framework/mlt_properties.c
>> +++ b/src/framework/mlt_properties.c
>> @@ -614,6 +614,7 @@ void mlt_properties_pass_property( mlt_properties
>> self,
>> mlt_properties that, con
>> return;
>>
>> mlt_property_pass( mlt_properties_fetch( self, name ), that_prop
>> );
>> +   mlt_events_fire( self, "property-changed", name, NULL );
>>  }
>>
>>  /** Copy all properties specified in a comma-separated list to another
>> properties list.
>>
>> 
>>
>> Thanks in advance for your opinion on this.
>>
>> Regards,
>> Jean-Baptiste
>>
>>
>>
>>
>>
>>
>>
>> ___
>> 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] Mlt::Properties pass_list not triggering property-changed

[Dan Dennedy]

On Fri, Jul 24, 2020 at 1:36 PM jb  wrote:

> Hi all,
>
> Looking at a timewarp producer issue in Kdenlive, I noticed that the MLT
> properties method "mlt_properties_pass_list" does not trigger a "property-
> changed" event.
>
> In Kdenlive, we use this "mlt_properties_pass_list" method to pass some
> properties on the producer. However, since the "property-changed" event is
> not
> triggered, the properties are not applied on the Timewarp producer that
> applies changes to the original avformat producer on the
> "property-changed"
> event.
>
> Is there any reason to not trigger a property-changed event in
> mlt_properties_pass_list ?
>

I do not recall there being a reason to not fire this event, and I do not
see anything in git log on this file about removing it. It is most likely
an oversight in the contributor's submission and review. As you can see
from the code comment and git blame it came from an infrequent contributor.
We can add this change and then if something is negatively affected try
blocking events in that area.


>
> If this is meant to be, I can change Kdenlive to use a property set
> method,
> but otherwise, it seems reasonable to fix it with this 1 line patch :
>
> 
>
> diff --git a/src/framework/mlt_properties.c
> b/src/framework/mlt_properties.c
> index 94afe45f..f3e419b5 100644
> --- a/src/framework/mlt_properties.c
> +++ b/src/framework/mlt_properties.c
> @@ -614,6 +614,7 @@ void mlt_properties_pass_property( mlt_properties
> self,
> mlt_properties that, con
> return;
>
> mlt_property_pass( mlt_properties_fetch( self, name ), that_prop );
> +   mlt_events_fire( self, "property-changed", name, NULL );
>  }
>
>  /** Copy all properties specified in a comma-separated list to another
> properties list.
>
> 
>
> Thanks in advance for your opinion on this.
>
> Regards,
> Jean-Baptiste
>
>
>
>
>
>
>
> ___
> 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] State of custom GLSL?

[Dan Dennedy]

On Sun, May 31, 2020 at 4:10 PM  wrote:

> Hm. In order to stick with "plain melt" I may modify an existing movit
> transition instead. Do you forsee any problems going this route?
>
>
It is not a bad idea to add something to the opengl module using the same
OpenGL context given to Movit. I would stay away from trying to actually
integrate with Movit itself for a generic shader and only use some more
standalone functions of GlslManager (or code snippets). You should also
take a look at filter_movit_convert.cpp to see how to integrate the image
I/O with MLT.

El 30 may 2020, a las 15:56, Dan Dennedy  escribió:
>
> On Sat, May 30, 2020 at 10:49 AM  wrote:
>
>> Hi all - what's the current state of running custom GLSL shaders for
>> effects and transitions in MLT? In 2017 it appears it wasn't supported, at
>> least using Movit.
>>
>> Specifically, I'd like to write shaders that take frames from multiple
>> producers as input.
>>
>>
> It is only possible for two inputs (transition) using WebGL with WebVfx.
> It includes an example based GL transitions <https://gl-transitions.com>:
>
> https://github.com/mltframework/webvfx/blob/master/demo/examples/transition-shader-glslio.html
>
> Otherwise, as a single input filter, there is an add-on to FFmpeg
> libavfilter to use GLSL that you would need to extend to read from a
> specified file.
>
> The nice thing about WebVfx is that it already provides the framework to
> make MLT properties - including animated with keyframes - available to the
> shader uniforms by way of the JavaScript required to use WebGL. Otherwise,
> a pure MLT plugin would require something to define how properties map to
> uniforms.
>
>
>
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] State of custom GLSL?

[Dan Dennedy]

On Sat, May 30, 2020 at 10:49 AM  wrote:

> Hi all - what's the current state of running custom GLSL shaders for
> effects and transitions in MLT? In 2017 it appears it wasn't supported, at
> least using Movit.
>
> Specifically, I'd like to write shaders that take frames from multiple
> producers as input.
>
>
It is only possible for two inputs (transition) using WebGL with WebVfx. It
includes an example based GL transitions :
https://github.com/mltframework/webvfx/blob/master/demo/examples/transition-shader-glslio.html

Otherwise, as a single input filter, there is an add-on to FFmpeg
libavfilter to use GLSL that you would need to extend to read from a
specified file.

The nice thing about WebVfx is that it already provides the framework to
make MLT properties - including animated with keyframes - available to the
shader uniforms by way of the JavaScript required to use WebGL. Otherwise,
a pure MLT plugin would require something to define how properties map to
uniforms.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] processing stops after 15,000 frames

[Dan Dennedy]

On Sun, May 10, 2020 at 5:18 PM Mark Polesky via Mlt-devel <
mlt-devel@lists.sourceforge.net> wrote:

> Hi, I tried to create a minimal video 20,000 frames long (should be 11min
> 7sec at 30fps), but melt stopped processing after 14,999 frames (leaving it
> 8min 20sec). Am I doing something wrong? Thanks
>
> test.mp4:
>
> 
> 
>frame_rate_den="1"/>
>   
> 
>
> command:
> $ melt test.mlt -consumer avformat:test.mp4
>


You need to set the length property on the color producer.

MLT is mainly for developers. Please remember to use our learn from the GUI
open source MLT apps.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] reducing xml filesizes with repetitive filters

[Dan Dennedy]

On Sun, May 10, 2020 at 1:10 AM Mark Polesky via Mlt-devel <
mlt-devel@lists.sourceforge.net> wrote:

> Hi,
>
> I asked this question on stackoverflow a few days ago.  Thought I'd hit up
> the mailing list to see if I might get a bite here:
> https://stackoverflow.com/questions/61628423/
>
> =
>
> Possibly related, but separate question:
>
> Let's say I have a file 'included.mlt':
>
> 
>
> If I want to include that file inside another, none of the usual methods
> seem to work:
>
> 1) XInclude
>
> 
> http://www.w3.org/2001/XInclude;>
>   
>   
> 
>
> Responds with:
> Failed to load "includer.mlt"
>
> 2) external general entity
>
> 
>  
> ]>
> 
>   
>   
> 
>
> Responds with:
> [producer_xml] parse fatal: Entity 'included' failed to parse
>   row: 7  col: 13
> Failed to load "includer.mlt"
>
> Is there any way to do it?
>
> Thanks
>
>



But it will not work with a minimal MLT XML containing only a 
for some reason. It must include that producer in a  or
. Basically, if you create that included.mlt using the following
it works:
melt color:blue out=555 -consumer xml:included.mlt

Also, you need to be aware that mixing frame rates between the XML files
does not work.
You can learn from how popular open source MLT apps are doing things if
they save or export MLT XML. In Shotcut this is made available through File
> Open MLT XML as Clip.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Crash in transition_mix

[Dan Dennedy]

On Thu, Feb 27, 2020 at 5:03 AM jb  wrote:

> Hi all,
>
>
> Following a Kdenlive's bug report, I reproducer a crash in transition_mix
> when using a "consumer" producer is inserted in a playlist, if that
> producer has a different fps than current project.
>
>
> Problem is that in consumer_producer, we have that:
>
> static int get_audio(...)
>
> (...)
>
> // if not repeating last frame
> if ( mlt_frame_get_position( nested_frame ) != cx->audio_position )
> {...}
>
> else
> {
> // otherwise return no samples  <-- this case seems to be
> triggered when producer fps is different
> *samples = 0;
> *buffer = NULL;
> }
>
> Having a NULL audio frame buffer and 0 samples is not correctly handled in
> transition_mix, leading to a crash in line 195:
>
> memcpy( >dest_buffer[self->dest_buffer_count * channels_a],
> buffer_a, bytes );
>
>
> Crash can be fixed by changing consumer_producer.c, adding this at line
> 101:
>
> *channels = 0;
>
>
> It triggers a bypass in transisiton_mix.c, preventing the crash.
>
> Would that be ok or should this better be fixed by changing transition_mix
> ?
>

I think the fix should be in transition_mix.c. How about

--- src/modules/core/transition_mix.c
+++ src/modules/core/transition_mix.c
@@ -141,3 +141,3 @@ static int transition_get_audio( mlt_frame frame_a,
void **buffer, mlt_audio_for
  // Prevent dividing by zero.
- if ( !channels_a || !channels_b )
+ if ( !channels_a || !channels_b || !buffer_a || !buffer_b )
  return 1;
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] New MLT release in March ?

[Dan Dennedy]

MLT version 6.20.0 and WebVfx 1.2.0 have been released.

On Mon, Feb 10, 2020 at 12:00 AM Jean-Baptiste Mardelle 
wrote:

> Hi all,
>
>
> We have a dependency freeze for Kdenlive in 4 weeks (on the 12th of
> March 2020).
>
> It would be very nice to have an MLT release around that date so that we
> can make use of the recent improvements (consumer preview scaling,
> rubberband module, etc) which are much wanted :).
>
> Thanks and let me know if I can help.
>
>
> Regards,
>
> Jean-Baptiste Mardelle
>
>
>
> ___
> Mlt-devel mailing list
> Mlt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>


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

Re: [Mlt-devel] GPU transcode possible?

[Dan Dennedy]

On Wed, Jan 29, 2020 at 9:31 AM Paul  wrote:

> Hi
>
> is it possible to have the complete decoding and encoding done on the
> GPU instead on the CPU?
>

No, hardware accelerated decoding is not integrated.


> I found various examples for Kdenlive encoding with my nvidia gpu with
> this command:
>
> "f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2 ab=384k"
>
> but this obviously only uses the gpu for encoding while decoding is
> still performed on the cpu.
>
> I can do the transcoding both on gpu with ffmpeg and this command line:
>
> "ffmpeg -hwaccel cuvid -c:v h264_cuvid -i input.MP4 -c:v h264_nvenc
> -pixel_format yuv420p -preset default output.mp4"
>
> which works very well, is this doable with mlt/kdenlive?
>
> greets
> Paul
>
> --
+-DRD-+
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Issue with new consumer scaling feature

[Dan Dennedy]

On Sat, Jan 18, 2020 at 3:04 PM Dan Dennedy  wrote:

> On Fri, Jan 17, 2020 at 12:59 AM jb  wrote:
>
>> Hi Dan, all,
>>
>> First, thanks a lot for implementing the much anticipated consumer
>> scaling
>> feature! Nice way to do it! While testing it, I noticed a problem with
>> transitions.
>>
>> It seems like the "consumer_scale" property is not always properly
>> propagated
>> to the frames. Because of this, transitions sometimes produce a "full
>> size"
>> image instead of a correctly scaled result.
>>
>> Issue is reproducible at least with the "composite", "affine" and
>> "qtblend"
>> transitions. It seems like the "consumer_scale" value is correct on the
>> a_frame but not on the b_frame.
>>
>> Changing this line (in the mentionned transition code) :
>> double resolution_scale = mlt_frame_resolution_scale(b_frame);
>>
>> to:
>> double resolution_scale = mlt_frame_resolution_scale(a_frame);
>>
>> fixes the issue.
>
>
> You are correct. I fixed it in qtblend and affine. However, composite has
> not been updated to use mlt_frame_resolution_scale(). When I looked into
> that today, I noticed it that it is already working by simply taking a
> ratio of the get_image() width and height arguments over the profile width
> and height. This rule was also in transition affine as`(double) *width /
> normalised_width;`. Thus, I am thinking about removing
> mlt_frame_resolution_scale(), the consumer scale property, and simply
> applying this technique everywhere.  Moreover, this can be done separately
> for width and height to make it slightly more accurate when one dimensions
> needs to change slightly more or less than the other in order to enforce a
> multiple of 2 or more. What do you think? Is there a situation where this
> is not desirable and an explicit scale is necessary?
>

I decided to drop the frame consumer_scale property and
mlt_frame_resolution_scale() in favor of the (request_width /
profile_width) approach. I found that when a service needs to disable
preview scaling (for example, vidstab) it also needs to communicate that to
filters before or after. It could do that by clearing the consumer_scale
property on the frame, but why add something that needs to be removed when
the information already exists and has a way to communicate: the width and
height references in get_image calls. Moreover, this provides the added
benefit of independent width and height scaling. There is still a "scale"
property on the consumer supported by melt and the xml producer to trigger
the usage of two different profiles, but you can remove it in kdenlive for
the embedded preview as I have just done for Shotcut. Documentation in the
form of a page on the web site is coming soon.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Issue with new consumer scaling feature

[Dan Dennedy]

On Fri, Jan 17, 2020 at 12:59 AM jb  wrote:

> Hi Dan, all,
>
> First, thanks a lot for implementing the much anticipated consumer scaling
> feature! Nice way to do it! While testing it, I noticed a problem with
> transitions.
>
> It seems like the "consumer_scale" property is not always properly
> propagated
> to the frames. Because of this, transitions sometimes produce a "full
> size"
> image instead of a correctly scaled result.
>
> Issue is reproducible at least with the "composite", "affine" and
> "qtblend"
> transitions. It seems like the "consumer_scale" value is correct on the
> a_frame but not on the b_frame.
>
> Changing this line (in the mentionned transition code) :
> double resolution_scale = mlt_frame_resolution_scale(b_frame);
>
> to:
> double resolution_scale = mlt_frame_resolution_scale(a_frame);
>
> fixes the issue.


You are correct. I fixed it in qtblend and affine. However, composite has
not been updated to use mlt_frame_resolution_scale(). When I looked into
that today, I noticed it that it is already working by simply taking a
ratio of the get_image() width and height arguments over the profile width
and height. This rule was also in transition affine as`(double) *width /
normalised_width;`. Thus, I am thinking about removing
mlt_frame_resolution_scale(), the consumer scale property, and simply
applying this technique everywhere.  Moreover, this can be done separately
for width and height to make it slightly more accurate when one dimensions
needs to change slightly more or less than the other in order to enforce a
multiple of 2 or more. What do you think? Is there a situation where this
is not desirable and an explicit scale is necessary?

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

Re: [Mlt-devel] 6.18.0 fails to build on some architectures

[Dan Dennedy]

On Mon, Dec 30, 2019 at 1:16 AM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Hi!
>
> On 12/30/19 9:55 AM, Patrick Matthäi wrote:
> > Ok the attached patch works fine :)
> >
> > Can you please push this patch to your repo?:
> >
> >
> > diff -Naur mlt-6.18.0.orig/src/modules/avformat/Makefile
> mlt-6.18.0/src/modules/avformat/Makefile
> > --- mlt-6.18.0.orig/src/modules/avformat/Makefile   2019-11-12
> 02:44:42.0 +0100
> > +++ mlt-6.18.0/src/modules/avformat/Makefile2019-12-19
> 09:51:18.816133573 +0100
> > @@ -1,5 +1,5 @@
> >  CFLAGS += -I../..
> > -LDFLAGS += -L../../framework -lmlt -lpthread -lm
> > +LDFLAGS += -L../../framework -lmlt -lpthread -lm -latomic
>
> You should probably prepend "-latomic" with "--as-needed".
>

We have that already in an included makefile.


>
> >  include ../../../config.mak
> >  include config.mak
> > diff -Naur mlt-6.18.0.orig/src/modules/avformat/producer_avformat.c
> mlt-6.18.0/src/modules/avformat/producer_avformat.c
> > --- mlt-6.18.0.orig/src/modules/avformat/producer_avformat.c
> 2019-11-12 02:44:42.0 +0100
> > +++ mlt-6.18.0/src/modules/avformat/producer_avformat.c 2019-12-19
> 09:50:07.476605820 +0100
> > @@ -68,6 +68,12 @@
> >  #define IMAGE_ALIGN (1)
> >  #define VFR_THRESHOLD (3) // The minimum number of video frames with
> differing durations to be considered VFR.
> >
> > +#ifndef HAVE_ATOMIC_INT_FAST64
> > +#  if !#defined(__arm__) && !#defined(__mips__) && !defined(__sh__)
> > +#define HAVE_ATOMIC_INT_FAST64 1
> > +#  endif
> > +#endif
>
> Why the architecture-specific "#ifdefs" here?
>
>
That was an earlier attempt to work around the build problem not knowing
what to do. It is not committed and not planning to do now.


> Note that the atomic issue is quite common as it is a result of a gcc
> bug, see [1]. We have fixed lots of Debian packages in the past with
> the exact same problem and normally it's a matter to manually link
> against libatomic with an additional --as-needed.
>
> Depending on your build system, you can test during the configure step
> whether libatomic is needed or not and then add dynamically, see for
> example [2].
>
> Adrian
>
> > [1] https://twitter.com/lporiginalg/status/121140726345424
> > [2]
> https://salsa.debian.org/mariadb-team/mariadb-10.3/blob/master/debian/patches/c11_atomics.patch
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>


Thank you a lot for your help.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] 6.18.0 fails to build on some architectures

[Dan Dennedy]

On Tue, Dec 17, 2019 at 5:32 AM Patrick Matthäi 
wrote:

> Hi
>
> Am 22.11.2019 um 21:24 schrieb Dan Dennedy:
> > On Wed, Nov 20, 2019 at 7:23 AM Patrick Matthäi 
> wrote:
> >> Hi,
> >>
> >> I just uploaded 6.18.0, but it FTBFS on some architectures like armel,
> mipsel etc:
> > Can you please test the attached patch?
>
> Sorry I were on vacation, I have tested it now:
>


> With this applied on 6.18.0 it still fails:
>
>
> https://buildd.debian.org/status/fetch.php?pkg=mlt=armel=6.18.0-2=1576577801=log
>


>

Some web searches suggest that `-latomic` is sometimes needed. You can add
that in src/modules/avformat/Makefile and see if it makes a difference.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] 6.18.0 fails to build on some architectures

[Dan Dennedy]

On Fri, Nov 22, 2019 at 12:24 PM Dan Dennedy  wrote:
>
> On Wed, Nov 20, 2019 at 7:23 AM Patrick Matthäi  wrote:
> >
> > Hi,
> >
> > I just uploaded 6.18.0, but it FTBFS on some architectures like armel, 
> > mipsel etc:
>
> Can you please test the attached patch?

Sorry, forget previous had cruft another change. Instead
diff --git a/src/modules/avformat/producer_avformat.c
b/src/modules/avformat/producer_avformat.c
index 46c16346..6ac46cc1 100644
--- a/src/modules/avformat/producer_avformat.c
+++ b/src/modules/avformat/producer_avformat.c
@@ -68,6 +68,12 @@
#define IMAGE_ALIGN (1)
#define VFR_THRESHOLD (3) // The minimum number of video frames with
differing durations to be considered VFR.
+#ifndef HAVE_ATOMIC_INT_FAST64
+# if !#defined(__arm__) && !#defined(__mips__) && !defined(__sh__)
+# define HAVE_ATOMIC_INT_FAST64 1
+# endif
+#endif
+
struct producer_avformat_s
{
   mlt_producer parent;
@@ -84,10 +90,15 @@ struct producer_avformat_s
   int audio_index;
   int video_index;
   int64_t first_pts;
+#if defined(HAVE_ATOMIC_INT_FAST64) && (HAVE_ATOMIC_INT_FAST64 != 0)
   atomic_int_fast64_t last_position;
+   atomic_int_fast64_t current_position;
+#else
+   int64_t last_position;
+   int64_t current_position;
+#endif
   int video_seekable;
   int seekable; /// This one is used for both audio and file level seekability.
-   atomic_int_fast64_t current_position;
   mlt_position nonseek_position;
   atomic_int top_field_first;
   uint8_t *audio_buffer[ MAX_AUDIO_STREAMS ];


mlt-fix-link-atomic64.diff
Description: Binary data
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] 6.18.0 fails to build on some architectures

[Dan Dennedy]

On Wed, Nov 20, 2019 at 7:23 AM Patrick Matthäi  wrote:
>
> Hi,
>
> I just uploaded 6.18.0, but it FTBFS on some architectures like armel, mipsel 
> etc:

Can you please test the attached patch?

diff --git a/src/modules/avformat/producer_avformat.c
b/src/modules/avformat/producer_avformat.c
index 46c16346..6ac46cc1 100644
--- a/src/modules/avformat/producer_avformat.c
+++ b/src/modules/avformat/producer_avformat.c
@@ -68,6 +68,12 @@
 #define IMAGE_ALIGN (1)
 #define VFR_THRESHOLD (3) // The minimum number of video frames with
differing durations to be considered VFR.

+#ifndef HAVE_ATOMIC_INT_FAST64
+#  if !#defined(__arm__) && !#defined(__mips__) && !defined(__sh__)
+#define HAVE_ATOMIC_INT_FAST64 1
+#  endif
+#endif
+
 struct producer_avformat_s
 {
  mlt_producer parent;
@@ -84,10 +90,15 @@ struct producer_avformat_s
  int audio_index;
  int video_index;
  int64_t first_pts;
+#if defined(HAVE_ATOMIC_INT_FAST64) && (HAVE_ATOMIC_INT_FAST64 != 0)
  atomic_int_fast64_t last_position;
+ atomic_int_fast64_t current_position;
+#else
+ int64_t last_position;
+ int64_t current_position;
+#endif
  int video_seekable;
  int seekable; /// This one is used for both audio and file level seekability.
- atomic_int_fast64_t current_position;
  mlt_position nonseek_position;
  atomic_int top_field_first;
  uint8_t *audio_buffer[ MAX_AUDIO_STREAMS ];
diff --git a/src/modules/lumas/create_lumas b/src/modules/lumas/create_lumas
index a86c8477..943911b1 100755
--- a/src/modules/lumas/create_lumas
+++ b/src/modules/lumas/create_lumas
@@ -4,6 +4,8 @@

 if [ "$(uname -s)" = "Darwin" ]; then
  export DYLD_LIBRARY_PATH=$LD_LIBRARY_PATH:../../framework
+elif uname -s | grep -iq mingw; then
+ export PATH=$PATH:../../framework
 else
  export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:../../framework
 fi


mlt-fix-link-atomic64.diff
Description: Binary data
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

[Mlt-devel] version 6.18.0 released

[Dan Dennedy]

https://github.com/mltframework/mlt/releases/tag/v6.18.0
-- 
+-DRD-+
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Next MLT release?

[Dan Dennedy]

I will aim for Nov 11.

On Sat, Nov 2, 2019 at 8:21 AM Dan Dennedy  wrote:

> I am on a vacation until Nov 6 and then have a couple other things to look
> into including the one you mentioned. So, it will not be 7 - 10 days.
> Yesterday, I set the GitHub milestone date for dec 12, but it will probably
> be sooner.
>
> On Fri, Nov 1, 2019 at 10:27 PM jb  wrote:
>
>> Hi Dan, all,
>>
>> We are approaching the dependency freeze for Kdenlive's 19.12 release and
>> would very much like to have a new MLT release so that we can have the
>> latest
>> fixes and features.
>>
>> If possible, a fix for the luma compositing issue I mentionned here would
>> be
>> great:
>>
>> https://github.com/mltframework/mlt/commit/
>>
>> 25cb58cd35812745571ce1062fdb6f5bd89a723b#diff-2470c5fc09e71ea19d149fed053952d8
>>
>> Ideally if we could get the release in something like 7-10 days it would
>> be
>> perfect. Let me know if I can do something.
>>
>> Best regards,
>>
>> Jean-Baptiste
>>
>>
>>
>>
>> ___
>> Mlt-devel mailing list
>> Mlt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>>
> --
> +-DRD-+
>
-- 
+-DRD-+
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Next MLT release?

[Dan Dennedy]

I am on a vacation until Nov 6 and then have a couple other things to look
into including the one you mentioned. So, it will not be 7 - 10 days.
Yesterday, I set the GitHub milestone date for dec 12, but it will probably
be sooner.

On Fri, Nov 1, 2019 at 10:27 PM jb  wrote:

> Hi Dan, all,
>
> We are approaching the dependency freeze for Kdenlive's 19.12 release and
> would very much like to have a new MLT release so that we can have the
> latest
> fixes and features.
>
> If possible, a fix for the luma compositing issue I mentionned here would
> be
> great:
>
> https://github.com/mltframework/mlt/commit/
>
> 25cb58cd35812745571ce1062fdb6f5bd89a723b#diff-2470c5fc09e71ea19d149fed053952d8
>
> Ideally if we could get the release in something like 7-10 days it would
> be
> perfect. Let me know if I can do something.
>
> Best regards,
>
> Jean-Baptiste
>
>
>
>
> ___
> Mlt-devel mailing list
> Mlt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>
-- 
+-DRD-+
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Build mlt with Python 3

[Dan Dennedy]

I did some research myself, and while there is not solution for all
combinations of OS and python installs, it seems using python3 is the best
option. It could be possible to make the build script's python executable
configurable, it is not really possible for the shebangs because there is
no install make target for them. So, I applied the patch, and if some thing
still needs python2, they can patch it for their build. Thanks


On Wed, Sep 18, 2019 at 1:01 AM Patrick Matthäi 
wrote:

> Am 02.09.2019 um 22:57 schrieb Dan Dennedy:
>
> AFAIK "python3" is not a standard name for the executable any may not be
> available on a python 3 only system. The patch needs to be backwards
> compatible and use python3 if available and just "python" otherwise.
>
> Hi,
>
> I have checked it on current Debian and Ubuntu 19.04 and if you only have
> python3 there is no /usr/bin/python. All Python  tools have the "3" in it.
>
> Python 2 will retire in january (https://pythonclock.org/) so I think it
> would be a good start for mlt in december to kick out Python2 support?
>
>
>
>
> On Mon, Sep 2, 2019 at 5:55 AM Janne Liljeblad 
> wrote:
>
>> I just got Flowblade launched with Python 3 bindings and the next
>> release is coming with Flowblade running on Python 3, so I support
>> making Python 3 the default for Python binding going forward.
>>
>> Regards,
>>
>> Janne
>>
>> On Mon, Sep 2, 2019 at 3:44 PM Patrick Matthäi 
>> wrote:
>> >
>> > Hi,
>> >
>> > I switched the Debian packaging from Python 2 to 3. Now there is the
>> > problem, that the path is not /usr/bin/python (same for python-config),
>> > but /u/b/python3{-config}.
>> >
>> > So I had to apply the attached diff to get it working with Python 3. I
>> > would welcome it if..
>> >
>> > 1) Python3 would become the default
>> >
>> > 2) Dynamic (or with configure switch) chose between python2 or 3
>> >
>> > --
>> > /*
>> > Mit freundlichem Gruß / With kind regards,
>> >  Patrick Matthäi
>> >  GNU/Linux Debian Developer
>> >
>> >   Blog: http://www.linux-dev.org/
>> > E-Mail: pmatth...@debian.org
>> > patr...@linux-dev.org
>> > */
>> >
>> > ___
>> > 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
>>
>
>
> --
> +-DRD-+
>
> --
> /*
> Mit freundlichem Gruß / With kind regards,
>  Patrick Matthäi
>  GNU/Linux Debian Developer
>
>   Blog: http://www.linux-dev.org/
> E-Mail: pmatth...@debian.org
> patr...@linux-dev.org
> */
>
>

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

Re: [Mlt-devel] RAM guidelines?

[Dan Dennedy]

On Wed, Sep 11, 2019 at 6:00 AM Brian Matherly via Mlt-devel <
mlt-devel@lists.sourceforge.net> wrote:

> > On Wednesday, September 11, 2019, 12:35:03 AM CDT, Kingsley G. Morse Jr.
>  wrote:
> >
> >
> > Can you suggest a reasonable amount of RAM for a
> > 64 bit computer, so it can edit videos with melt's
> > framework and kdenlive?
> >
> > At the moment, I tend to
> > 1.) render to 1920x1080 .webm
> > 2.) use special effects
> > 3.) use compose/transform transitions
> > 4.) produce videos only a few minutes long
> > 5.) with maybe 8 video and 3 audio tracks
> >
> > I wouldn't be surprised if, in the foreseeable
> > future, there comes a time when I'm interested in
> > editing a project with up to 15 video and 7 audio
> > tracks, maybe up to 2 hours long.
> >
> > Can you suggest a reasonable amount of RAM?
> >
> > Thanks,
> > Kingsley
>
> This is probably relevant:
> https://shotcut.org/FAQ/#what-are-the-minimum-system-requirements
>
> 8GB would be a good minimum.
>
> ~Brian
> I'm
>

I agree. Consider the 8 GB guideline for people with existing computers.
For a new computer I recommend at least 16. You basically need more than
double what melt alone needs if you run melt in the background of a MLT GUI
editor.  It is also convenient to not have to close everything else you may
be using.

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

Re: [Mlt-devel] Did you intend to call mlt_frame.c:620 recursively?

[Dan Dennedy]

This is normal looking and not recursive. It is impossible to call
mlt_frame_get_image() only once on the stack unless you are making a custom
media player. You are not running out of memory on the stack with a call
depth of only 53. If you had made a project that includes itself, then it
would become recursive and blow out the stack. mlt_pool uses heap memory,
and you are out of heap memory. This requires the usual sorts of thing to
reduce. Outside of melt reduce other applications. In Kdenlive reduce your
resolution, number of tracks, and number of processing thread. Use 64-bit
to access more than 3 GiB RAM.


On Mon, Sep 9, 2019 at 3:28 PM Kingsley G. Morse Jr. 
wrote:

> Hey guys,
>
> Thanks again for maintaining melt.
>
> It's lot of fun!
>
> I happened to stumble on a use case for version
> 6.16.0-4 of debian's package that elicits
>
> "[mlt_pool] out of memory"
>
> while rendering edits from version 19.08.0-1 of
> debian's kdenlive.
>
> My commands?
>
> $ gdb --args melt tmp/bug.2.mlt
>
> (gdb) b mlt_log if level == 8
> (gdb) r
> (gdb) bt
> (gdb) bt full
>
> 2 back traces are attached.
>
> One lean.
>
> One full.
>
> I see repeated calls to mlt_frame.c:620.
>
> Did you mean to call it recursively?
>
> (Maybe you could save memory by calling it only
> once.)
>
> Thanks,
> Kingsley
>
> PS: Maybe something like exit.c should be called
> after logging "[mlt_pool] out of memory" on
> line 161 of mlt_pool.c.
>
> --
> Time is the fire in which we all burn.
>
> ___
> Mlt-devel mailing list
> Mlt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>


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

Re: [Mlt-devel] Build mlt with Python 3

[Dan Dennedy]

AFAIK "python3" is not a standard name for the executable any may not be
available on a python 3 only system. The patch needs to be backwards
compatible and use python3 if available and just "python" otherwise.


On Mon, Sep 2, 2019 at 5:55 AM Janne Liljeblad 
wrote:

> I just got Flowblade launched with Python 3 bindings and the next
> release is coming with Flowblade running on Python 3, so I support
> making Python 3 the default for Python binding going forward.
>
> Regards,
>
> Janne
>
> On Mon, Sep 2, 2019 at 3:44 PM Patrick Matthäi 
> wrote:
> >
> > Hi,
> >
> > I switched the Debian packaging from Python 2 to 3. Now there is the
> > problem, that the path is not /usr/bin/python (same for python-config),
> > but /u/b/python3{-config}.
> >
> > So I had to apply the attached diff to get it working with Python 3. I
> > would welcome it if..
> >
> > 1) Python3 would become the default
> >
> > 2) Dynamic (or with configure switch) chose between python2 or 3
> >
> > --
> > /*
> > Mit freundlichem Gruß / With kind regards,
> >  Patrick Matthäi
> >  GNU/Linux Debian Developer
> >
> >   Blog: http://www.linux-dev.org/
> > E-Mail: pmatth...@debian.org
> > patr...@linux-dev.org
> > */
> >
> > ___
> > 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
>


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

Re: [Mlt-devel] Bug#934590: libmlt-data: The package became bloated

[Dan Dennedy]

Just a quick update to mention that this change has been committed to git
master for next release, which will come before the end of the year.

On Tue, Aug 13, 2019 at 2:53 PM Горбешко Богдан 
wrote:

> On 13.08.2019 22:22, Dan Dennedy wrote:
> > On Mon, Aug 12, 2019 at 5:27 AM Patrick Matthäi  > <mailto:pmatth...@debian.org>> wrote:
> >
> > Am 12.08.2019 um 13:11 schrieb Горбешко Богдан:
> > > Package: libmlt-data
> > > Version: 6.16.0-3
> > > Severity: minor
> > >
> > > Dear Maintainer,
> > >
> > > After the last upgrade, the package became about 230 MBs larger,
> > > because of a lot of large lumas in PGM format, each about 4 MBs. Is
> > > there an important reason to keep them uncompressed on a disk? Even
> > > the fast GZip compression can drastically reduce their size.
> > >
> > Hi Dan,
> >
> > what is your opionion about this? This is the list of the affected
> > files:
> >
> >
> > This was intentional to produce transitions with the correct aspect
> > ratio. The PGM images cannot be simply gzip compressed because the PGM
> > reader in MLT is not integrated with zlib. Instead, the package can
> > use the configure option --luma-compress to output compressed PNG.
> > However, these are 8-bit instead of the 16-bit PGM, which provides
> > better quality transitions. Since these are procedurally-generated, I
> > started working on a change to generate the image on-demand instead of
> > reading a file. I plan to do that for the next release.
> >
> Okay; thanks for explanation!
>
>

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

Re: [Mlt-devel] Bug#934590: libmlt-data: The package became bloated

[Dan Dennedy]

On Mon, Aug 12, 2019 at 5:27 AM Patrick Matthäi 
wrote:

> Am 12.08.2019 um 13:11 schrieb Горбешко Богдан:
> > Package: libmlt-data
> > Version: 6.16.0-3
> > Severity: minor
> >
> > Dear Maintainer,
> >
> > After the last upgrade, the package became about 230 MBs larger,
> > because of a lot of large lumas in PGM format, each about 4 MBs. Is
> > there an important reason to keep them uncompressed on a disk? Even
> > the fast GZip compression can drastically reduce their size.
> >
> Hi Dan,
>
> what is your opionion about this? This is the list of the affected files:
>

This was intentional to produce transitions with the correct aspect ratio.
The PGM images cannot be simply gzip compressed because the PGM reader in
MLT is not integrated with zlib. Instead, the package can use the configure
option --luma-compress to output compressed PNG. However, these are 8-bit
instead of the 16-bit PGM, which provides better quality transitions. Since
these are procedurally-generated, I started working on a change to generate
the image on-demand instead of reading a file. I plan to do that for the
next release.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Is melt the right thing for realtime switching/mixing live sources?

[Dan Dennedy]

On Wed, Jun 26, 2019 at 1:23 PM Anatoly  wrote:

> Hello,
> I am faced with a need in opensourced software video switcher engine. I
> need not any GUI at all, because I'm planning to attach hardware
> console to control it.
> I briefly read some docs and take a quick look at examples, they
> almost about non-live time domain, non-live sources. Still I can't
> fugure out if it is right tool for my task? Should I dig deeper or
> better try something else?
>
>
It can but some may consider it overkill for some basic switching.
The source repo contains a python example switcher with super simple web UI
and REST API:
https://github.com/mltframework/mlt/blob/master/src/swig/python/switcher.py

This works with two decklink SDI/HDMI inputs and outputs to another
decklink. If you need to do realtime encoding + streaming, that might be
possible on strong hardware and x264 tuning. If you need to decode two live
stream sources, MLT is not the strongest when it comes to live streaming
playback but it may be satisfactory; it depends on many things but
especially the streaming format.

This switcher example was made for a client's specific need, so it includes
a video mixer that places one input into the 80% top right corner over the
top of the other input. This is more advanced than most needs. You can
change this to do a quick dissolve or remove it to simply cut over.
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] New MLT release?

[Dan Dennedy]

Sure, I will make a new release within a couple of weeks.


On Mon, Mar 11, 2019 at 12:56 AM Jean-Baptiste Mardelle 
wrote:

> Hi Dan, all.
>
>
> As you might know, we are finally planning to release Kdenlive's big
> rewrite. We are beginning the  countdown, and it would be nice to have a
> new MLT release so that we can benefit from the latest fixes/changes.
>
> I don't know if you have any release schedule but ideally for us it
> would be great to have MLT 6.14 out soon. Would that be possible?
>
>
> Thanks a lot,
>
> Jean-Baptiste Mardelle
>
>
>
> ___
> Mlt-devel mailing list
> Mlt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>


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

Re: [Mlt-devel] Video luma argument?

[Dan Dennedy]

On Wed, Feb 20, 2019 at 10:07 PM  wrote:

> Apologies in advance for a semi-novice question:
>
> I'm looking for a way to achieve something like the luma transition, but
> using a greyscale video instead of a PGM file for the luma map file.
>
> The first frame of the greyscale video will be all white; the last all
> black (or vice-versa). What I'd like is for that white/black to correspond
> to the alpha, so that everywhere that's fully-black in the greyscale video,
> we can "see through" to the second full-color clip. Everywhere that's 50%
> black will be a 50-50 mix of the first and second clips, etc.
>
> Is this possible?
>
> Thanks!
> Tom
>

Use the shape filter and set the "use_luminance" property to 1. You might
also want to set "audio_match" to 0 to prevent audio from being affected
and set "use_mix" to 0 to prevent the "threshold" behavior of the classic
luma transition. This basically copies the luma from the "resource"
property's producer to the alpha channel. Then, you need to use any number
of compositing transitions. I am sorry this filter is under documented and
you need to read the source or use Shotcut's Mask: From File filter to
learn about it.

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

Re: [Mlt-devel] Playback DNG/TIFF files

[Dan Dennedy]

For TIFF, something like "melt imgseq/%04d.tiff ttl=25
where the 4 in "%04d" is the number of digits used in your sequence file
names and 25 is the number of frames to repeat each image.
I do not think there is anything to read DNG. MLT's image sequence support
uses either Qt or GDK pixbuf for image loaders.


On Wed, Feb 13, 2019 at 4:23 PM Joel Nash  wrote:

> I have captured a RAW file using magic lantern on the canon 5d mark ii and
> converted the file to separate each frame into a DNG file and TIFF file.
>
> Can melt playback a single image for the length of a frame rate?
> If so how would I run this command ?
>
> Many thanks,
>
> Joel
> ___
> Mlt-devel mailing list
> Mlt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>


-- 
+-DRD-+
___
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?

[Dan Dennedy]

On Fri, Dec 7, 2018 at 11:55 AM Tom Murphy  wrote:

> Ah, and another criterion I forgot but could be important is the
> ability to quickly seek / jump around in a melt video.
>
>
Some people in the Shotcut forum working on proxy and intermediate file
workflows seem mostly impressed with the Ut Video codec, but that is
lossless compressed. Also, currently, to use it one must be sure to supply
colorspace and color_range flags to ffmpeg command line to ensure proper
output. Unfortunately, that is quite a large file, which is not great for
long intermediate files. DNxHD is still good and is smaller, but it has
limited support for resolutions and frame rates. If you need something that
compresses similar (i.e. visually lossless) to DNxHD, is fast, and
flexible; consider to use ProRes. I have not done a deep study of the three
prores encoder implementations in ffmpeg, but I have tended to favor
prores_ks.

https://trac.ffmpeg.org/wiki/Encode/VFX#Prores


> 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 mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] melt: add support for consumer in/out

[Dan Dennedy]

On Fri, Dec 7, 2018 at 11:27 AM jb  wrote:

> Hi,
>
> In shotcut, the  tag is used in the playlist's xml to pass
> consumer
> arguments, allowing to render a playlist file with melt whitout passing
> extra
> arguments.
>
> I am considering using the same approach for Kdenlive, but there is one
> small
> missing feature for us:
>
> it would be useful to allow rendering only part of the playlist using this
> method. My idea was to allow in/out attributes on the consumer that would
> then
> be passed on the producer to allow rendering only a part of the project.
>
> A simple patch to melt, like mine below, implements the feature.
>
> Would you be ok to include such feature ?
>
>
Yes, go ahead and commit it directly.


> Thanks
> Jean-Baptiste
>
> ---
> diff --git a/src/melt/melt.c b/src/melt/melt.c
> index ab3a0ab4..300f9c88 100644
> --- a/src/melt/melt.c
> +++ b/src/melt/melt.c
> @@ -972,11 +972,18 @@ query_all:
>
> // Get the last group
> mlt_properties group = mlt_properties_get_data(
> melt_props,
> "group", 0 );
> -
> +
> // Apply group settings
> mlt_properties properties =
> MLT_CONSUMER_PROPERTIES( consumer
> );
> mlt_properties_inherit( properties, group );
> -
> +   int in = mlt_properties_get_int( properties, "in"
> );
> +   int out = mlt_properties_get_int( properties,
> "out" );
> +   if ( in > 0 || out > 0 ) {
> +   if ( out == 0 ) {
> +   out = mlt_producer_get_length(
> melt ) - 1;
> +   }
> +   mlt_producer_set_in_and_out(melt, in, out);
> +   }
> // Connect consumer to melt
> mlt_consumer_connect( consumer,
> MLT_PRODUCER_SERVICE( melt )
> );
>
>
>
>
> ___
> 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] frame count / cut

[Dan Dennedy]

On Thu, Aug 30, 2018 at 9:35 AM Joel Nash  wrote:

> As I'm editing film on the RPI melt doesn't yet playback smoothly so
> instead, I use omxplayer to playback film after making edits with melt.
>
> To specify a point in time in melt one uses frames. However omxplayer can
> only go as specific as seconds.
>
> So, on playback using omxplayer ill say to start at 02:05 (for example).
>
> and this will mean ill have to go (125 seconds * 23.976025 fps)
> to know where to tell melt to start playback.
> This was the exact command i used.
>
> melt cut1.mp4 in=2997.5 out=3117.4 -consumer avformat:cut2.mp4
> vcodec=libxvid b=5000k
>
>
You are using frame units for time values, and MLT does not support more
than frame precision. Thus, those values are truncated:
duration = 3117 - 2997 + 1 = 121 frames ~= 5.05 sec


> on playback however of the new cut2.mp4 file with omxplayer the footage
> includes what previously equated to 122 mabybe 123 seconds omplayer.
>

I think you mean frames instead of seconds. You should use something
besides omxplayer to get the output duration. Something like melt -consumer
xml or ffprobe.


> Why is this inaccuracy happening?
>
>
MP4 uses temporal compression with codec delays. This can make outputs
slightly longer than expected when draining the codec. One frame in my test
using:

melt -profile atsc_1080p_2398 noise: in=2997 out=3117 -consumer
avformat:test.mp4

ffprobe shows test.mp4 as 5.08 sec and melt shows length 122 frames.

If you change the output to intra-only with uncompressed audio (I don't
give a shit if raspberry pi can play it or not):

melt -profile atsc_1080p_2398 noise: in=2997 out=3117 -consumer
avformat:test.mkv vcodec=ffv1 acodec=pcm_s16le

Then, ffprobe reports 5.05 sec and melt shows length 121 frames, which is
spot on.

Next, if I use ffmpeg 4.0.2 to convert that output to H.264/AAC MP4:

ffmpeg -i test.mkv test2.mp4

Then, ffprobe shows 5.07 sec and melt shows length 122 frames - same as MLT
MP4 output.

If that MP4 output bothers you enough, you can take it up with ffmpeg-devel.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Colour Correction

[Dan Dennedy]

I will tell you what I tell all other would be melt users. See one of the
MLT-based GUI video editors. They all offer color correction. So, yes, it
is possible. You just need to learn more about melt by reading the
documentation on the web site and figure out how to translate what the apps
are doing to the command line. Yeah, it's not easy. No one should say video
editing and filtering on the command line is easy. There are basic example
command lines in the demo subdirectory of the source tree.


On Thu, Aug 30, 2018 at 9:24 AM Joel Nash  wrote:

> After following the melt tutorials on youtube its not clear if its
> possible to carry out colour corrections in melt? Can I do this on the
> command line some how?
>
> Best,
> J
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mlt-devel mailing list
> Mlt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] xml limits

[Dan Dennedy]

On Sun, Aug 12, 2018 at 7:56 AM Carl Karsten  wrote:

> How much system resources (memory and file handles) does each "file
> producer" use?
>

Not much because MLT objects are quite small, and all the main file
producers (avformat, qimage, pixbuf) utilize mlt_cache. Caching might sound
like holding more in memory than needed, but it is just the opposite here.
They put big (images) and handly (file/socket) things into the cache that
can be restored when there is a cache miss. When least recently things are
evacuated from the cache, those resources are released, and the MLT object
that must stay is like an empty shell.


> (I think that's the question I want.)
>
> I expect to have 9000 1 second references to 5 source files.
>

You can have 5 producer elements - one for each file - that you reference
by id many times.


>
> Because I am trying to make the audio better, and this is the best I
> can come up with:  for each second, look at rms of channel 0, if it is
> below a threashhold (because the intermittent mic receiver went off)
> "copychannel 1 0"  (channel 1 is the mic on the camera, which is
> better than nothing.)
>
> If I was a C coder I would make a filter or something, but I'm barely
> able to do this in Python, and the best I could come up with was make
> a producer for each second and set the channelcopy filter.   I could
> group them and reduce it to 100 or 200, but if I don't need to, why
> bother?
>
> I'm trying to do some a 20 second test, but that isn't going well,
> likely because my test box is congested and who knows what, but I
> figured I should find out if my 9000 number has a chance of working on
> 8gig.
>
>
I am not sure about those kind of numbers.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] small optimization in producer_color

[Dan Dennedy]

Please try this diff:

diff --git a/src/modules/core/producer_colour.c
b/src/modules/core/producer_colour.c
index 3942877f..eafa434e 100644
--- a/src/modules/core/producer_colour.c
+++ b/src/modules/core/producer_colour.c
@@ -1,6 +1,6 @@
 /*
  * producer_colour.c
- * Copyright (C) 2003-2017 Meltytech, LLC
+ * Copyright (C) 2003-2018 Meltytech, LLC
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -190,12 +190,18 @@ static int producer_get_image( mlt_frame frame,
uint8_t **buffer, mlt_image_form
}

// Create the alpha channel
-   int alpha_size = *width * *height;
-   uint8_t *alpha = mlt_pool_alloc( alpha_size );
+   int alpha_size = 0;
+   uint8_t *alpha = NULL;

// Initialise the alpha
-   if ( alpha )
-   memset( alpha, color.a, alpha_size );
+   if (color.a < 255 || *format == mlt_image_rgb24a) {
+   alpha_size = *width * *height;
+   alpha = mlt_pool_alloc( alpha_size );
+   if ( alpha )
+   memset( alpha, color.a, alpha_size );
+   else
+   alpha_size = 0;
+   }

// Clone our image
if (buffer && image && size > 0) {
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] small optimization in producer_color

[Dan Dennedy]

On Sat, Aug 4, 2018 at 6:51 AM Jean-Baptiste Mardelle 
wrote:

> On 03.08.2018 19:46, Dan Dennedy wrote:
>
> On Fri, Aug 3, 2018 at 10:23 AM Jean-Baptiste Mardelle 
> wrote:
>
>> Hi all,
>>
>> I recently realized that the color producer always creates an alpha
>
> mask, and uses the rgba24a format by default.
>>
>
> Typically, it will receive a format from the downstream consumer services,
> and it will only choose this default if movit is used or mlt_image_none is
> received.
>
>
> Hi Dan,
>
> Thanks for your answer.
>
>
>> In fact, unless the color has an alpha value under 255, it is
>> unnecessary and we could simply use an rgb24 format, saving some memory.
>>
>> I am mostly interested in this because the qtblend transition checks if
>> a producer has an alpha channel before deciding whether a compositing is
>> required. Having a useless alpha channel on the color producer causes
>> unnecessary compositing and slowdowns in this case. Would you be ok to
>> change the color producer to use rgb24 or rgb24a formats depending on
>> the alpha value ?
>>
>>
> Only in the truly default case. If qtblend requests mlt_image_rgb24a and
> the color producer returns mlt_image_rgb24, then the image conversion
> filter will automatically convert it. That is slightly less efficient than
> directly returning what is requested.
>
>
> Ok, I realize I didn't correctly analyze the situation. You are totally
> right that in most cases, the format will be determined by the consumer
> services.
> In fact, the optimization would be to only create the alpha mask if the
> consumer requests an rgba format or if the alpha is less than 255.
>
> something like:
>
> +   uint8_t *alpha = NULL;
> +   if (color.a < 255 || *format == mlt_image_rgb24a) {
> +   alpha = mlt_pool_alloc( alpha_size );
> +   (...)
>
>
> If the consumer requests yuv4222 and the color has no transparency, it
> doesn't make sense to create an alpha mask ?
>
>
You are probably correct, and the above change is safe. I will give it a
try.


>
> For frei0r.cairoblend, I check every pixel's alpha until it sees one that
> is not 255. See transition_frei0r.c:is_opaque().
>
>
>
> Sure but it seems to me that simply checking for the presence of an alpha
> mask would be much faster than checking every pixel of a frame..
>

True, and I could add that check as well before checking every pixel.


>
> Thanks & regards
>
>
> Jean-Baptiste
>
>
>
>
>
>> I can provide a patch if you think this is a welcome change.
>>
>>
>> Best regards
>>
>> Jean-Baptiste
>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] small optimization in producer_color

[Dan Dennedy]

On Fri, Aug 3, 2018 at 10:23 AM Jean-Baptiste Mardelle 
wrote:

> Hi all,
>
> I recently realized that the color producer always creates an alpha

mask, and uses the rgba24a format by default.
>

Typically, it will receive a format from the downstream consumer services,
and it will only choose this default if movit is used or mlt_image_none is
received.


> In fact, unless the color has an alpha value under 255, it is
> unnecessary and we could simply use an rgb24 format, saving some memory.
>
> I am mostly interested in this because the qtblend transition checks if
> a producer has an alpha channel before deciding whether a compositing is
> required. Having a useless alpha channel on the color producer causes
> unnecessary compositing and slowdowns in this case. Would you be ok to
> change the color producer to use rgb24 or rgb24a formats depending on
> the alpha value ?
>
>
Only in the truly default case. If qtblend requests mlt_image_rgb24a and
the color producer returns mlt_image_rgb24, then the image conversion
filter will automatically convert it. That is slightly less efficient than
directly returning what is requested.

For frei0r.cairoblend, I check every pixel's alpha until it sees one that
is not 255. See transition_frei0r.c:is_opaque().


>
> I can provide a patch if you think this is a welcome change.
>
>
> Best regards
>
> Jean-Baptiste
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Huge memory usage by the webvfx plugin

[Dan Dennedy]

On Tue, Jul 31, 2018 at 10:14 AM Lu Wang  wrote:

> Hi All,
>
>   Yesterday I noticed the huge memory usage by the webvfx plugin, as melt
> crashed due to "out of memory". My mlt project contains only one track,
> which contains a serious of clips, say C1, C2, ... There might be standard
> simple transitions between clips.
>
>   A webvfx filter is attached for each cilp. The filter will load a
> complicated HTML page which involves 3d map etc. The page may use up to 1GB
> memory in practice.
>
>   I noticed that whenever a new cilp starts being rendered, melt will use
> 1GB memory more memory. At first I thought it's some memory leak in
> QtWebKit, but after playing around with the webvfx files
> , I noticed that
> services (also filters, effects) are being created but never destroyed!
> From the code it seems that the objects will be destroyed when the whole
> rendering sequence is finished, but I couldn't verify that as melt always
> crashed before finishing.
>
>   This means that, say when C5 is being rendered, the webvfx filters for
> C1 - C4 still exist in memory, which will actually never be used again.
>
>
The MLT execution engine does not know whether the project will be accessed
sequentially or randomly (seeking). By default, all MLT objects are held in
memory until the project is closed (as well as all mlt_frames). The
mlt_playlist takes a property called "autoclose" which if you set to 1 will
close each producer in its list after it is done. You can set this in XML
on the  element: autoclose=1. However, I suspect there are
scenarios where this will not work.


>
>   I can think of only 2 possible solutions:
>
> 1. To reuse existing webvfx plugin. I might try to hack to code, to use
> some singleton service/filter/effect internally. But this is too hacky and
> may not work in general for other projects.
>
>
Some services should not hold everything it manages in memory or file
handles per process and memory will be exhausted. For that, they use
mlt_cache to store objects they are using (think buffers or library structs
- not MLT object) and keep a limited number of them open or in-memory. It
is then responsible for restoring the object when it gets a cache hit. You
can see this at work in avformat, pixbuf, and qimage producers.


> 2. To unload a plugin which is no longer needed, but I'm not sure how to
> do so. It seems that the frames are rendered individually and the filters
> are loaded on demand. Are there events/signals when a clip is fully
> rendered?
>
>   What do you think?
>
>

>
>   regards,
>   - Lu
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mlt-devel mailing list
> Mlt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Adjust playback speed/rate of entire playlist or tractor

[Dan Dennedy]

Yes, that's correct. Well, to be more accurate, the current set of
consumers does not support audio where the speed is not 1. It sounds like
for what you want, some non-trivial analysis and changes are required.


On Wed, Jul 18, 2018 at 3:55 PM Steve Rubin  wrote:

> Thanks. I tried that function before, and from what I understand (from
> other threads in this mailing list), it doesn't support audio. Is that
> correct?
>
> On Wed, Jul 18, 2018 at 3:47 PM, Dan Dennedy  wrote:
>
>> Use mlt_producer_set_speed() on the tractor (or playlist as seen in
>> melted):
>>
>> https://www.mltframework.org/doxygen/structmlt__producer__s.html#a15cb033f194e160cc9f62ce0b3080ff9
>>
>> Despite the speed being a double, decimals digits are truncated, and
>> speed less than one for slower than realtime are not supported in a default
>> build. There is a unsupported build option that makes the mlt_position type
>> use double instead of int32_t (define DOUBLE_MLT_POSITION), but there is
>> definitely going to be breakage if you use that. Basically, this value is
>> added to a frame number-based counter of type mlt_position in the producer.
>> Negative values are supported to play in reverse. If you look in
>> src/melt/melt.c you can see this function being used.
>>
>>
>>
>> On Wed, Jul 18, 2018 at 3:39 PM Steve Rubin  wrote:
>>
>>> I understand that the timewarp producer manipulates a producer's
>>> playback rate. Is there a way to adjust the playback rate of a higher order
>>> producer, e.g., a playlist or tractor?
>>>
>>> This would enable a straightforward implementation of a project-level
>>> playback speed option in a DAW/NLE (rather than having to do fine-grained
>>> management of playback rates on each producer).
>>>
>>> Thanks,
>>> Steve
>>>
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Mlt-devel mailing list
>>> Mlt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Adjust playback speed/rate of entire playlist or tractor

[Dan Dennedy]

Use mlt_producer_set_speed() on the tractor (or playlist as seen in melted):
https://www.mltframework.org/doxygen/structmlt__producer__s.html#a15cb033f194e160cc9f62ce0b3080ff9

Despite the speed being a double, decimals digits are truncated, and speed
less than one for slower than realtime are not supported in a default
build. There is a unsupported build option that makes the mlt_position type
use double instead of int32_t (define DOUBLE_MLT_POSITION), but there is
definitely going to be breakage if you use that. Basically, this value is
added to a frame number-based counter of type mlt_position in the producer.
Negative values are supported to play in reverse. If you look in
src/melt/melt.c you can see this function being used.



On Wed, Jul 18, 2018 at 3:39 PM Steve Rubin  wrote:

> I understand that the timewarp producer manipulates a producer's playback
> rate. Is there a way to adjust the playback rate of a higher order
> producer, e.g., a playlist or tractor?
>
> This would enable a straightforward implementation of a project-level
> playback speed option in a DAW/NLE (rather than having to do fine-grained
> management of playback rates on each producer).
>
> Thanks,
> Steve
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mlt-devel mailing list
> Mlt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Humble test suggestion (Was: 6f7e79: Use mlt_pool ...)

[Dan Dennedy]

I just re-ran your test with the latest, correct! change for MLT_USE_POOL,
and RES usage did not exceed 370 MiB

On Wed, Jun 27, 2018 at 4:55 PM Dan Dennedy  wrote:

> On Wed, Jun 27, 2018 at 3:13 PM Kingsley G. Morse Jr. 
> wrote:
>
>> Hi Dan,
>>
>> Thank you very much for freely sharing your time,
>> skills and software.
>>
>> I can imagine mlt becoming even more popular.
>>
>> The main reason I'm writing is I happened to
>> notice a plan to use mlt_pool by default.
>>
>> Maybe you remember it resulted in a large,
>> wasteful memory footprint back in March.
>>
>> (That email follows.)
>>
>>
> The biggest improvement in memory reduction from your case came from the
> change in the affine transition:
>
> https://github.com/mltframework/mlt/commit/e426a4ed62c7f674db4498766d6928a9598a7ca9
>
>
>
>> You very reasonably and responsibly anticipated
>> more testing.
>>
>> Humble suggestion:
>>
>> Use my little kdenlive project to test if mlt_pool
>> still uses too much memory.
>>
>> All my files are at
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890848
>>
>> I'd like to avoid a regression.
>>
>>
> The change to stop using mlt_pool is causing stability regressions, which
> is less desirable than the memory saving it provides.
>
>
>> Thanks,
>> Kingsley
>>
>>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Humble test suggestion (Was: 6f7e79: Use mlt_pool ...)

[Dan Dennedy]

On Wed, Jun 27, 2018 at 3:13 PM Kingsley G. Morse Jr. 
wrote:

> Hi Dan,
>
> Thank you very much for freely sharing your time,
> skills and software.
>
> I can imagine mlt becoming even more popular.
>
> The main reason I'm writing is I happened to
> notice a plan to use mlt_pool by default.
>
> Maybe you remember it resulted in a large,
> wasteful memory footprint back in March.
>
> (That email follows.)
>
>
The biggest improvement in memory reduction from your case came from the
change in the affine transition:
https://github.com/mltframework/mlt/commit/e426a4ed62c7f674db4498766d6928a9598a7ca9



> You very reasonably and responsibly anticipated
> more testing.
>
> Humble suggestion:
>
> Use my little kdenlive project to test if mlt_pool
> still uses too much memory.
>
> All my files are at
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890848
>
> I'd like to avoid a regression.
>
>
The change to stop using mlt_pool is causing stability regressions, which
is less desirable than the memory saving it provides.


> Thanks,
> Kingsley
>
> On 06/27/2018 14:14, GitHub wrote:
> >   Branch: refs/heads/master
> >   Home:   https://github.com/mltframework/mlt
> >   Commit: 6f7e7915b039e24cd82207d7db9ac780f0d84bb3
> >
> https://github.com/mltframework/mlt/commit/6f7e7915b039e24cd82207d7db9ac780f0d84bb3
> >   Author: Dan Dennedy 
> >   Date:   2018-06-27 (Wed, 27 Jun 2018)
> >
> >   Changed paths:
> > M src/framework/mlt_pool.c
> >
> >   Log Message:
> >   ---
> >   Use mlt_pool by default pending more testing.
> >
> > Use `-DUSE_MLT_POOL=0` in CFLAGS to turn off mlt_pool.
> >
> > Fixes https://github.com/mltframework/shotcut/issues/604
> >
> >
> >
> >   **NOTE:** This service been marked for deprecation:
> https://developer.github.com/changes/2018-04-25-github-services-deprecation/
> >
> >   Functionality will be removed from GitHub.com on January 31st,
> 2019.
>
> >
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
> > ___
> > Mlt-devel mailing list
> > Mlt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mlt-devel
>
> >> Date: Fri, 16 Mar 2018 16:39:15 -0700
> >> From: GitHub 
> >> To: mlt-devel@lists.sourceforge.net
> >> Message-ID:
> <5aac55a3cdd15_183ac2ac3e0121c0897...@hookshot-fe-dfcc362.cp1-iad.github.net.mail
> >
> >>
> >>   Branch: refs/heads/master
> >>   Home:   https://github.com/mltframework/mlt
> >>   Commit: 71167e65b4ac126546b7524e406bd81f991c2abf
> >>
> https://github.com/mltframework/mlt/commit/71167e65b4ac126546b7524e406bd81f991c2abf
> >>   Author: Dan Dennedy 
> >>   Date:   2018-03-16 (Fri, 16 Mar 2018)
> >>
> >>   Changed paths:
> >> M src/framework/mlt_pool.c
> >>
> >>   Log Message:
> >>   ---
> >>   Require C macro USE_MLT_POOL to use memory pool.
> >>
> >> mlt_pool can result in a large, wasteful memory footprint for the
> >> application. Relates to issue #271. Add "-DUSE_MLT_POOL" to CFLAGS to
> >> make MLT use its mlt_pool memory pool. Otherwise, it will use malloc(),
> >> realloc(), and free().
> >>
> >>
> >>   Commit: e426a4ed62c7f674db4498766d6928a9598a7ca9
> >>
> https://github.com/mltframework/mlt/commit/e426a4ed62c7f674db4498766d6928a9598a7ca9
> >>   Author: Dan Dennedy 
> >>   Date:   2018-03-16 (Fri, 16 Mar 2018)
> >>
> >>   Changed paths:
> >> M src/modules/plus/transition_affine.c
> >>
> >>   Log Message:
> >>   ---
> >>   Reduce memory usage of affine esp. with large images.
> >>
> >>
> >> Compare:
> https://github.com/mltframework/mlt/compare/3021e900b5c6...e426a4ed62c7
> >> ==_mimepart_5aac55a3cd983_183ac2ac3e0121c08977be
> >> Content-Type: text/plain; charset="us-ascii"
> >> MIME-Version: 1.0
> >> Content-Transfer-Encoding: 7bit
> >> Content-Disposition: inline
> >>
> >> ___
> >> Mlt-devel mailing list
> >> Mlt-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/mlt-devel
> >>
> >> ==_mimepart_5aac55a3cd983_183ac2ac3e0121c08977be--
>
> --
> Time is the fire in which we all burn.
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mlt-devel mailing list
> Mlt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Recent change to comsumer_xml corrupts projects

[Dan Dennedy]

On Mon, Jun 18, 2018 at 4:42 AM Jean-Baptiste Mardelle 
wrote:

> Hi all,
>
>
> Hope you are doing fine and great to see the recent activity on MLT. One
> recent change causes problems in Kdenlive and will also in other
> applications:
>
>
> https://github.com/mltframework/mlt/commit/c091cae3a34fe9046e7ed610bd64d2df3c11dfe0
>
> With this change, any property containing an "=" sign will be converted
> to animation. However, this is not wanted in some cases, for example if
> you want to display a text with an equal sign:
>
> melt -consumer qtext text="frame=1" -consumer xml
>
> This will change the text to "0=1" because it tries to translate the
> text string to an animation property. This also currently breaks
> kdenlivetitle producer because it stores some xml data, including equal
> signs, in the "xmldata" property.
>
> Maybe this animation parsing should not be done on "string" type
> properties? Any idea?
>

Thank you for finding and reporting the regression! I believe I fixed it by
removing the code bits following:
// Force a string with keyframes to be parsed with mlt_animation ...

As a result, one cannot supply an animated property by a string and get it
converted to another clock string format without some intervention to cause
the property to be evaluated as animation (by getting its value at a
position).
It should be noted that string properties can be animated ala timed text-
only with no interpolation.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] MLT/Shotcut Specification: ID stability

[Dan Dennedy]

The IDs are only needed to facilitate XML references. There are no rules
other than standard XML ID/IDREF rules: within a document IDs must be
unique and IDREFs should refer to valid IDs. Anything beyond that is
external to MLT and probably onerous. Shotcut uses the xml consumer to
generate MLT XML, and its convention. Applications can use any ID
convention of their choosing and may change them. With that said, Kdenlive,
Shotcut, and the Wikimedia Video Editing Server all use the same algorithm
to generate a hash over media files that is faster than hashing the entire,
possibly very large, media file.
https://github.com/mltframework/shotcut/blob/master/src/mainwindow.cpp#L1040
https://github.com/ddennedy/wikimedia-video-editing-server/blob/master/application/controllers/Job.php#L181
Obviously, there is some potential for hash collision, but there is no
mechanism in place to handle it.


On Thu, Apr 26, 2018 at 5:39 PM Allan Reyes  wrote:

> Hey folks,
>
> A bit of a strange question, but I don't see any mention of this in the
> MLT documentation. Is there any central specification or convention on how
> NLEs handle IDs? I know the naming conventions tend to be a bit different,
> e.g. Shotcut (producer0, producer1...), but is there anything with regards
> to ID stability? Specifically, are NLEs "allowed" to change IDs if they're
> already set? e.g. a user adds some resource in the middle of the playlist,
> is there any restriction in the spec that the NLE implementation should
> only create a unique ID for that specific resource without modifying the
> other IDs?
>
> The motivation here is that I'm looking for a stable identifier for assets
> (images, video clips, etc.) to map to uploaded assets (e.g. AWS S3) and
> want to make sure it covers as many MLT-backed editors as possible. If this
> isn't in the MLT spec, is it something worth considering?
>
> Thanks!
>
> Cheers,
> Allan
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mlt-devel mailing list
> Mlt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] how to exit at clip end?

[Dan Dennedy]

add "terminate_on_pause=1" to your consumer


On Fri, Mar 30, 2018 at 10:36 AM Federico Allegretti 
wrote:

> when i play trough melt some clips, how could i say to melt to
> terminate after rendering and playback the last frame?
>
> --
> Open TV Architecture project: http://sourceforge.net/projects/otva/
>
> Messagenet VOIP: 5338759
>
> YouTube Channel: v1p3r's lab
>
> VIMEO HD videos: http://www.vimeo.com/user1912745/videos
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mlt-devel mailing list
> Mlt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] experimenting with melt and decklink

[Dan Dennedy]

On Thu, Mar 29, 2018 at 10:26 AM Federico Allegretti 
wrote:

> hello.
>
> experiemnting with melt by command line.
>
> Trying to exit trough the deckink consumer like that:
> melt -consumer decklink file1 file2 file3 ...
>
> I forced the fact really hard i suppose, in fact some files are 1080,
> some 720, some SD and also i mixed 25fps and 30fps clips :D
>
> Seems decklink do not love this mess :D
>
>
decklink consumer does not care about mixing the video attributes such as
this. melt will read the first file, get its attributes, and generate a
mlt_profile from them. Then, the decklink consumer must try to find one of
its preset video modes

[1] that matches the profile. I do not know what happened in your case, but
it sounds like perhaps the match failed, and decklink failed to initialize.


> Is there a trick to "rescale" all of the incoming video iles to a
> common size/framerate?
>

Use the "-profile " option and choose a compatible profile
from the list reported by "melt -query profiles"


>
> upscale to 1080 if HDMI selected trough blackmagic set util or
> downscale to SD if analog SD video output was set?
>
> I tried with resize e rescale filters .. but nothing changed.
>

Scaling is automatic to the profile. Everything is either scaled up or
down, preserving aspect ratio, and adding black bar padding where needed
(no cropping). If you want to center crop to remove black bars you can add
"-attach crop center=1" following every clip you want to apply it to. If
you want full control over scaling/pan/crop, you need to apply a filter
such as affine - see one of the GUI MLT apps for examples of usage.


>
> PS: this set is know by the user and no need to detect it by system
> properties.
>
> Cheers,
>
> Federico
>


> --
> Open TV Architecture project: http://sourceforge.net/projects/otva/
>
> Messagenet VOIP: 5338759
>
> YouTube Channel: v1p3r's lab
>
> VIMEO HD videos: http://www.vimeo.com/user1912745/videos
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mlt-devel mailing list
> Mlt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Detecting alpha in avformat producer

[Dan Dennedy]

On Wed, Mar 28, 2018 at 12:15 AM Jean-Baptiste Mardelle <j...@kdenlive.org>
wrote:

> On Monday, March 26, 2018 3:44:09 PM CEST, Brian Matherly wrote:
> > On 3/26/2018 1:49 AM, Jean-Baptiste Mardelle wrote:
> >> On 23.03.2018 18:42, Dan Dennedy wrote: ...
>
> Hi,
>
> > I think you have a few options:
> >
> > 1) Create a new image type in MLT: mlt_image_yuva444p16
> > I do not recommend this because it would be a lot of work.
> >
> > 2) Convert to mlt_image_yuv422p16 + alpha buffer
> > This option might be OK. You still lose half of the chroma
> > information converting from 444 to 422. And also, I would
> > recommend converting the alpha channels to an 8bit alpha buffer
> > because it would be a lot of work to find all the places that
> > use the alpha buffer and make sure they work with > 8 bits.
> >
> > 3) Convert to mlt_image_rgb24a
> > This would be my recommendation because it is the simplest.
> > Yes, you will lose some precision going from 40bpp to 32bpp. But
> > everything would just work and all you have to change is the
> > avformat_producer.
>
> Sure the 3rd option is much simpler, and since MLT doesn't currently
> support > 8bit buffers it won't make much difference in the result.
> A simple patch is in my github's fork:
>
>
> https://github.com/j-b-m/mlt/commit/d8c723130e34da7680b50b47bc31a927ef6414cd
>
> It supports both missing formats from the bugreport
> https://bugs.kde.org/show_bug.cgi?id=391963
>
> However more pixel formats will probably require the same adjustments in
> the future.
>
>
There are some areas where 10-bit video can be used through
mlt_image_yuv422p16, primarily only for input and output via decklink and
avformat. With some work, it can be added into movit integration for 16-bit
float processing. However, the change mentioned above will work until that
is done.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] webm encoding reports 1000fps

[Dan Dennedy]

OK, please someone commit it.

On Tue, Mar 27, 2018 at 3:08 PM Brian Matherly 
wrote:

>
> > Following Kdenlive's bug report:
> >
> > https://bugs.kde.org/show_bug.cgi?id=392294
> >
> > I noticed that encoding to webm with the avformat consumer produces
> > files reporting an incorrect fps (1000fps). Some googling suggested to
> > enforce the fps on the stream, and the following patch produces files
> > that report a correct fps. However not sure if this can have side
> > effects...
> >
> > Any comments on that ?
> >
> > Regards
> >
> > jb
> >
> > ---
> >
> > diff --git a/src/modules/avformat/consumer_avformat.c
> > b/src/modules/avformat/consumer_avformat.c
> > index c3724d13..edb157c9 100644
> > --- a/src/modules/avformat/consumer_avformat.c
> > +++ b/src/modules/avformat/consumer_avformat.c
> > @@ -792,6 +792,10 @@ static AVStream *add_video_stream( mlt_consumer
> > consumer, AVFormatContext *oc, A
> >  #endif
> > st->time_base = c->time_base;
> >
> > +   // Enforce fps
> > +   c->framerate = av_inv_q(st->time_base);
> > +   st->avg_frame_rate = c->framerate;
> > +
> > // Default to the codec's first pix_fmt if possible.
> > c->pix_fmt = pix_fmt ? av_get_pix_fmt( pix_fmt ) :
> > codec ?
> > ( codec->pix_fmts ? codec->pix_fmts[0] :
> > AV_PIX_FMT_YUV422P ): AV_PIX_FMT_YUV420P;
> >
> Looks legit to me. Ffmpeg does the same thing:
> http://ffmpeg.org/doxygen/trunk/ffmpeg_8c_source.html#l03372
>
> I'm not sure the comment and blank line are necessary. I would suggest:
>  st->time_base = c->time_base;
>  st->avg_frame_rate = av_inv_q(c->time_base);
>  c->framerate = av_inv_q(c->time_base);
>
> ~Brian
>
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mlt-devel mailing list
> Mlt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] Detecting alpha in avformat producer

[Dan Dennedy]

Do not forget to check libavutil version when adding more pixfmts.


On Fri, Mar 23, 2018 at 6:31 AM Brian Matherly 
wrote:

>
> On 3/23/2018 2:47 AM, Jean-Baptiste Mardelle wrote:
> > Hi all,
> >
> > In order to optimize performance, in the qtblend transition (in the qt
> > module), I try to detect if the top frame in the transition has
> > transparency, and if it doesn't, instead of performing the transition I
> > just return the top frame.
> >
> > However currently, to check if a frame has transparency I use the
> > following:
> >
> > if ( *format == mlt_image_rgb24a || mlt_frame_get_alpha( b_frame ) )
> > {
> > // The frame has an alpha channel
> > }
> >
> > However, some YUV formats with alpha, like AV_PIX_FMT_YUVA444P10LE,
> > don't obey these rules since the alpha buffer is not created.
>
> I predict the problme is not in the qtblend transition. The problem is
> probably that the avformat_producer is not creating the alpha channel.
>
> Maybe the problem is that AV_PIX_FMT_YUVA444P10LE is not handled here:
>
> https://github.com/mltframework/mlt/blob/master/src/modules/avformat/producer_avformat.c#L1391
>
> And/Or maybe it needs to be added here:
>
> https://github.com/mltframework/mlt/blob/master/src/modules/avformat/producer_avformat.c#L1184
>
> > Shouldn't the alpha buffer be created by default for this codecs, or is
> > there any other way to detect that the frame has alpha?
> >
> > Thanks for your advice.
> >
> > You can find sample video files in this bug report:
> > https://bugs.kde.org/show_bug.cgi?id=391963
> >
> > Regards
> >
> > Jean-Baptiste
>
> ~Brian
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mlt-devel mailing list
> Mlt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Re: [Mlt-devel] A smaller test case now elicits "[mlt_pool] out of memory"

[Dan Dennedy]

On Fri, Mar 16, 2018 at 12:52 PM Dan Dennedy <d...@dennedy.org> wrote:

> I took some time today to build kdenlive (master branch) and test this
> out...
>
> On Thu, Feb 22, 2018 at 12:20 AM Jean-Baptiste Mardelle <j...@kdenlive.org>
> wrote:
>
>> On 17.02.2018 05:55, Kingsley G. Morse Jr. wrote:
>> > I'm happy to provide you with an even smaller and
>> > easier test case.
>> >
>> > Just
>> >
>> >  1.) copy the attached tar archive "bug.2.tar"
>> >  to the /tmp directory and
>> >
>> >  2.) do what the attached video shows
>> >
>> >  $ cd /tmp
>> >
>> >  $ tar -xvf bug.2.tar
>> >
>> >  $ kdenlive bug.2.kdenlive
>> >
>> >  Select track Video 3's Affine transition
>> >  by clicking on it with the mouse
>> >
>> >  Click on the "Go to next key frame"
>> >  button.
>> >
>> >  Wait a moment for
>> >
>> >  "[mlt_pool] out of memory"
>> >
>> >  in the console.
>>
>
> I did not get the above error even though my system only has 6 GiB RAM and
> only 2.7 free at this time with Gnome Shell, Firefox with 2 tabs, and a
> terminal window open. However, running top in the terminal I do observe the
> RES going up to about 2.4g when running this test.
>
>
>>
>> Hi all,
>>
>> Sorry for the late feedback. So I made a few tests and found some
>> interesting facts.
>> The problem seems related to frame buffer.
>>
>> When setting the "buffer" property to 0 on the consumer (sdl2_audio) in
>> Kdenlive, the memory usage stays stable (around 500Mb).
>>
>> When setting the buffer to 25 (default in Kdenlive), I get 2 different
>> situations:
>> - When using an HD 25fps profile, memory usage goes to about 700Mb
>> - When using a SD NTSC profile, memory usage quickly goes up to 2.3Gb.
>>
>>
> The only way I was able to reproduce the above was by using the Project
> Settings dialog in Kdenlive to change the profile because in that case, for
> me, images no longer load and all I get is black in the preview area. If I
> edit the .kdenlive file to change the profile element, then I still
> reproduce a high memory usage. Curiously, the lower resolution does use
> about 200 MiB more than 1280x720 in my tests. The frame rate did not make a
> difference. Also, it is not really necessary to select the Affine effect
> and click next keyframe. Simply scrubbing the timeline or switching to
> Project Monitor and playing the project through also uses up to ~2.4g RES.
>
>
>> These tests were done with the image attached in the latest email
>> (3800x2500 jpeg).
>>
>
> At this point, I should point out that, in MLT, using high resolution
> images with affine generally requires a lot of memory. This is because
> affine requests the full source resolution from the source producer and
> bypasses the automatic scaling to project resolution. It does this so you
> can use affine to crop and scale and take advantage of all the available
> resolution. Imagine a heavy cropping scenario like a portrait photo
> included in a 16:9 video resolution and wanting little-to-no black bars.
> Best to do that by cropping from the original image instead of scaling
> original image down to 1280x720, cropping top and bottom to achieve 16:9,
> and then scaling that up to fill the video frame.
>
> Affine works in RGBA such that there are 4 bytes per pixel. As a result
> 3800 * 2500 * 4 = ~36.24 MiB. If for some reason - for example, lack of
> optimizations - there are 2 of these per MLT frame (after all there are 2
> affine effects in the project), and there are 25 MLT frames in the consumer
> buffer JB mentions above; then 36.24 MiB * 2 * 25 ~= 1.8 GiB. Add to that
> memory used by the MLT  and Kdenlive, and we start to approach the RES
> number I was seeing. I should also point out that the RES number stays
> around this high level and does not grow excessively while scrubbing,
> playing, and clicking next keyframe.
>
> Playing the project with "melt -consumer sdl2 buffer=1" uses ~1.5g RES
> where buffer=25 makes it shoot up to 2.8g.
> Now I can take a closer look at what can be done to reduce memory usage.
>
>
I made a couple of key experiments. In bug
https://github.com/mltframework/mlt/issues/271#issuecomment-373797288
I question the continued value of mlt_pool. I made a simple compile-time
option to replace it with malloc() and free(). As a result my particular
melt test case reduced from 1.75g RE