mltframework
mlt 7.28.0_1 crashes sometimes
The version installed is mlt 7.28.0_1, in brew.sh in macOS 15.1 with chip M1.
% brew list mlt
/opt/homebrew/Cellar/mlt/7.28.0_1/bin/melt
/opt/homebrew/Cellar/mlt/7.28.0_1/include/mlt-7/ (60 files)
/opt/homebrew/Cellar/mlt/7.28.0_1/lib/libmlt++-7.7.28.0.dylib
/opt/homebrew/Cellar/mlt/7.28.0_1/lib/libmlt-7.7.28.0.dylib
/opt/homebrew/Cellar/mlt/7.28.0_1/lib/cmake/ (4 files)
/opt/homebrew/Cellar/mlt/7.28.0_1/lib/mlt/ (21 files)
/opt/homebrew/Cellar/mlt/7.28.0_1/lib/pkgconfig/ (3 files)
/opt/homebrew/Cellar/mlt/7.28.0_1/lib/ (4 other files)
/opt/homebrew/Cellar/mlt/7.28.0_1/sbom.spdx.json
/opt/homebrew/Cellar/mlt/7.28.0_1/share/mlt/ (349 files)
Sometimes crashes during conversion and others completes successfully. The mlt file has been generated with kdenlive:
% melt -progress project-1.mlt
Trace/BPT trap: 5 487757, percentage: 74
Thanks for trying , but the log file is not helping very much. We need project-1.mlt. Then, I can try to substitute with my own media and see if it reproduces. If so, then run in a debugger.
I can't attach the mlt file and the mp4 file because I don't own the rights of the files and contain copyrighted data. But I could try to reproduce the issue with any free sample file and attach all files. It can take me a lot of time so don't close the issue whenever possible.
I ran it in the debugger on my Linux machine using the tip of git master without fail.
I ran it once using the Shotcut 24.10.29 build of melt for macOS on my M1 without fail, but I am trying again with a different video. I am not willing to install, test, and debug the Homebrew version you are using on my only Apple Silicon machine as it the build machine for Shotcut/macOS that uses MacPorts.
You can try to use Shotcut's melt to see if it is different: /Applications/Shotcut.app/Contents/MacOS/melt
With this version of melt fails(kdenlive crashes) so I tested with the brew.sh version: /Applications/kdenlive.app/Contents/MacOS/melt
This is why I recommended you to have a test mp4 file alongside with the mlt. If I can reproduce it in all melt versions (also Shotcut.app) I can try debugging it if you don't have the M1. I could check if it happens in macOS with Intel, and test it in a virtual machine.
But it will take some time.
I did not reproduce it after 2 more tests on my M1.
With this version of melt fails(kdenlive crashes)
That is confusing and not what I am doing or suggested. You cannot mix and match pieces of the Shotcut and Kdenlive app bundles.
I recommended you to have a test mp4 file
I already have a test mp4 file. I do not have yours, of course, because you said you cannot share it. I understand that. It looks pretty normal from the metadata in the XML file, and FFmpeg is very robust against corrupt data. But it is possible that it is needed. What created your input.mp4?
if you don't have the M1
I already told you that I do, and I tested it successfully 3 times now.
Here is exactly how I testing:
- download and install Shotcut 24.10.29
- run it once to let macOS verify it
/Applications/Shotcut.app/Contents/MacOS/melt mlt_bug_1049-mym1.mlt
Both and neither. It is a program of its own (not made by kdenlive or shotcut) that uses FFmpeg LIBRARIES (does not run ffmpeg program).
I can't provide right now sample files that reproduce the issue, maybe doesn't happen anymore? I think it's most likely a bug in ffmpeg libraries anyway. Closing with the intention to reopen in the future when sample files are available.
Reopening since I've found a video which reproduces always the issue, on Apple M1:
$ /opt/homebrew/bin/melt -progress project-2.mlt
Trace/BPT trap: 5 112974, percentage: 25
$ /Applications/Shotcut.app/Contents/MacOS/melt project-2.mlt
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|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 |
+---------------------------------------------------------------------+
Trace/BPT trap: 5 215877
$ /Applications/kdenlive.app/Contents/MacOS/melt project-2.mlt
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|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 |
+---------------------------------------------------------------------+
Trace/BPT trap: 5 106960
I tested your new files on my M1 Mac with melt in Shotcut 24.10.29 and Kdenlive 24.08.03 twice each, and it did not crash. Since these are signed with the hardened runtime, I cannot run them in a debugger. I will next test an unsigned Shotcut build running in a debugger, which sometimes reveals a problem.
I'm going to try a few more times. May it be related with not enough RAM memory or something? It doesn't look like since melt doesn't take that much RAM but just in case.
Tried one more time and the issue is reproducible:
$ /opt/homebrew/bin/melt project-2.mlt
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|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 |
+---------------------------------------------------------------------+
Trace/BPT trap: 5 276180
Will try with the x86_64 version of macOS to see if happens.
I ran it twice in the debugger with no problem. I think at this point since only you can reproduce it you need to try to fix it yourself.
Keeps failing with latest shotcut-macos-241117.dmg:
$ /Applications/Shotcut.app/Contents/MacOS/melt project-2.mlt
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|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 |
+---------------------------------------------------------------------+
Trace/BPT trap: 5 5161
You will need lldb, which can come from Xcode, but you may need to run sudo xcode-select -s /Library/Developer/CommandLineTools to use it at the command line. And sudo xcode-select -s /Applications/Xcode.app/ when you are done.
Get the unsigned dmg of Shotcut and extract that somewhere.
Run
lldb -- ~/shotcut/Shotcut.app/Contents/MacOS/melt -verbose -project ~/Movies/1049/project-2.mlt
When it crashes type bt
Crash with shotcut-macos-unsigned-241117.dmg:
$ lldb -- ./Shotcut.app/Contents/MacOS/melt -verbose -project debian.mlt
(lldb) target create "./Shotcut.app/Contents/MacOS/melt"
Current executable set to '/Volumes/debian/Shotcut.app/Contents/MacOS/melt' (arm64).
(lldb) settings set -- target.run-args "-verbose" "-project" "debian.mlt"
(lldb) run
Process 6726 launched: '/Volumes/debian/Shotcut.app/Contents/MacOS/melt' (arm64)
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|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 @ 0x129691990] using SAR=1/1
[libx264 @ 0x129691990] using cpu capabilities: ARMv8 NEON
[libx264 @ 0x129691990] profile High, level 5.0, 4:2:0, 8-bit
[libx264 @ 0x129691990] 264 - core 157 - H.264/MPEG-4 AVC codec - Copyleft 2003-2018 - http://www.videolan.org/x264.html - options: cabac=1 ref=8 deblock=1:0:0 analyse=0x3:0x133 me=umh subme=9 psy=1 psy_rd=1,00:0,00 mixed_ref=1 me_range=16 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=12 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=2 keyint=15 keyint_min=1 scenecut=40 intra_refresh=0 rc_lookahead=15 rc=crf mbtree=1 crf=18,0 qcomp=0,60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1,40 aq=1:1,00
[h264 @ 0x12ace8730] Reinit context to 1920x1088, pix_fmt: yuv420p
[h264 @ 0x12ace9710] Reinit context to 1920x1088, pix_fmt: yuv420p
[h264 @ 0x12acef120] Reinit context to 1920x1088, pix_fmt: yuv420p
[producer avformat] audio: total_streams 1 max_stream 1 total_channels 2 max_channels 2
[AVIOContext @ 0x12ab960e0] Statistics: 14269579 bytes read, 2 seeks
[h264 @ 0x12acebad0] Reinit context to 1920x1088, pix_fmt: yuv420p
[h264 @ 0x12a908c20] Reinit context to 1920x1088, pix_fmt: yuv420p
[h264 @ 0x12acec410] Reinit context to 1920x1088, pix_fmt: yuv420p
[producer avformat] audio: total_streams 1 max_stream 1 total_channels 2 max_channels 2
[AVIOContext @ 0x12aceb430] Statistics: 14269579 bytes read, 2 seeks
[chain avformat-novalidate] /Volumes/debian/input.mp4
checking VFR: pkt.duration 1500
[chain avformat-novalidate] /Volumes/debian/input.mp4
checking VFR: pkt.duration 1500
[h264 @ 0x12acf7a70] Reinit context to 1920x1088, pix_fmt: yuv420p
Process 6726 stopped 60017
* thread #7, stop reason = EXC_BREAKPOINT (code=1, subcode=0x1983a72c4)
frame #0: 0x00000001983a72c4 libsystem_c.dylib`localeconv_l.cold.2 + 24
libsystem_c.dylib`localeconv_l.cold.2:
-> 0x1983a72c4 <+24>: brk #0x1
libsystem_c.dylib`memstream_update.cold.1:
0x1983a72c8 <+0>: pacibsp
0x1983a72cc <+4>: stp x29, x30, [sp, #-0x10]!
0x1983a72d0 <+8>: mov x29, sp
Target 0: (melt) stopped.
(lldb) bt
* thread #7, stop reason = EXC_BREAKPOINT (code=1, subcode=0x1983a72c4)
* frame #0: 0x00000001983a72c4 libsystem_c.dylib`localeconv_l.cold.2 + 24
frame #1: 0x0000000198333864 libsystem_c.dylib`localeconv_l + 352
frame #2: 0x0000000198330a20 libsystem_c.dylib`__vfprintf + 172
frame #3: 0x000000019835c45c libsystem_c.dylib`_vsnprintf + 224
frame #4: 0x000000019833b050 libsystem_c.dylib`__sprintf_chk + 60
frame #5: 0x00000001000be12c libmlt-7.7.dylib`mlt_events_fire + 100
frame #6: 0x00000001001912fc libmltavformat.so`consumer_thread + 5472
frame #7: 0x000000019849b2e4 libsystem_pthread.dylib`_pthread_start + 136
(lldb) frame select 5
frame #5: 0x00000001000be12c libmlt-7.7.dylib`mlt_events_fire + 100
libmlt-7.7.dylib`mlt_events_fire:
-> 0x1000be12c <+100>: add x1, sp, #0x8
0x1000be130 <+104>: mov x0, x21
0x1000be134 <+108>: mov x2, #0x0 ; =0
0x1000be138 <+112>: bl 0x1000ce2cc ; mlt_properties_get_data
(lldb) frame variable
error: debug map object file "/Users/ddennedy/shotcut/src/mlt/src/framework/CMakeFiles/mlt.dir/mlt_events.c.o" containing debug info does not exist, debug info will not be loaded
(lldb) thread select 7
* thread #7, stop reason = EXC_BREAKPOINT (code=1, subcode=0x1983a72c4)
frame #0: 0x00000001983a72c4 libsystem_c.dylib`localeconv_l.cold.2 + 24
libsystem_c.dylib`localeconv_l.cold.2:
-> 0x1983a72c4 <+24>: brk #0x1
libsystem_c.dylib`memstream_update.cold.1:
0x1983a72c8 <+0>: pacibsp
0x1983a72cc <+4>: stp x29, x30, [sp, #-0x10]!
0x1983a72d0 <+8>: mov x29, sp
(lldb) disassemble -f
libmlt-7.7.dylib`mlt_events_fire:
0x1000be0c8 <+0>: sub sp, sp, #0xc0
0x1000be0cc <+4>: stp x22, x21, [sp, #0x90]
0x1000be0d0 <+8>: stp x20, x19, [sp, #0xa0]
0x1000be0d4 <+12>: stp x29, x30, [sp, #0xb0]
0x1000be0d8 <+16>: add x29, sp, #0xb0
0x1000be0dc <+20>: nop
0x1000be0e0 <+24>: ldr x8, 0x1000dc010 ; (void *)0x00000001fd5b8b58: __stack_chk_guard
0x1000be0e4 <+28>: ldr x8, [x8]
0x1000be0e8 <+32>: stur x8, [x29, #-0x28]
0x1000be0ec <+36>: cbz x0, 0x1000be1b8 ; <+240>
0x1000be0f0 <+40>: mov x19, x2
0x1000be0f4 <+44>: mov x20, x1
0x1000be0f8 <+48>: adr x1, 0x1000da921 ; "_events"
0x1000be0fc <+52>: nop
0x1000be100 <+56>: mov x2, #0x0 ; =0
0x1000be104 <+60>: bl 0x1000ce2cc ; mlt_properties_get_data
0x1000be108 <+64>: cbz x0, 0x1000be1b8 ; <+240>
0x1000be10c <+68>: ldr x21, [x0, #0x8]
0x1000be110 <+72>: str x20, [sp]
0x1000be114 <+76>: adr x3, 0x1000da929 ; "list:%s"
0x1000be118 <+80>: nop
0x1000be11c <+84>: add x0, sp, #0x8
0x1000be120 <+88>: mov w1, #0x0 ; =0
0x1000be124 <+92>: mov w2, #0x80 ; =128
0x1000be128 <+96>: bl 0x1000d9304 ; symbol stub for: __sprintf_chk
-> 0x1000be12c <+100>: add x1, sp, #0x8
0x1000be130 <+104>: mov x0, x21
0x1000be134 <+108>: mov x2, #0x0 ; =0
0x1000be138 <+112>: bl 0x1000ce2cc ; mlt_properties_get_data
0x1000be13c <+116>: cbz x0, 0x1000be1b8 ; <+240>
0x1000be140 <+120>: mov x21, x0
0x1000be144 <+124>: bl 0x1000cd62c ; mlt_properties_count
0x1000be148 <+128>: cmp w0, #0x1
0x1000be14c <+132>: b.lt 0x1000be1b8 ; <+240>
0x1000be150 <+136>: mov w20, #0x0 ; =0
0x1000be154 <+140>: mov w22, #0x0 ; =0
0x1000be158 <+144>: b 0x1000be170 ; <+168>
0x1000be15c <+148>: add w22, w22, #0x1
0x1000be160 <+152>: mov x0, x21
0x1000be164 <+156>: bl 0x1000cd62c ; mlt_properties_count
0x1000be168 <+160>: cmp w22, w0
0x1000be16c <+164>: b.ge 0x1000be1bc ; <+244>
0x1000be170 <+168>: mov x0, x21
0x1000be174 <+172>: mov x1, x22
0x1000be178 <+176>: mov x2, #0x0 ; =0
0x1000be17c <+180>: bl 0x1000ce170 ; mlt_properties_get_data_at
0x1000be180 <+184>: cbz x0, 0x1000be15c ; <+148>
0x1000be184 <+188>: ldr x8, [x0]
0x1000be188 <+192>: cbz x8, 0x1000be15c ; <+148>
0x1000be18c <+196>: add x8, x0, #0xc
0x1000be190 <+200>: ldar w8, [x8]
0x1000be194 <+204>: cbnz w8, 0x1000be15c ; <+148>
0x1000be198 <+208>: ldr x8, [x0]
0x1000be19c <+212>: ldr x8, [x8]
0x1000be1a0 <+216>: ldp x9, x1, [x0, #0x10]
0x1000be1a4 <+220>: mov x0, x8
0x1000be1a8 <+224>: mov x2, x19
0x1000be1ac <+228>: blr x9
0x1000be1b0 <+232>: add w20, w20, #0x1
0x1000be1b4 <+236>: b 0x1000be15c ; <+148>
0x1000be1b8 <+240>: mov w20, #0x0 ; =0
0x1000be1bc <+244>: ldur x8, [x29, #-0x28]
0x1000be1c0 <+248>: nop
0x1000be1c4 <+252>: ldr x9, 0x1000dc010 ; (void *)0x00000001fd5b8b58: __stack_chk_guard
0x1000be1c8 <+256>: ldr x9, [x9]
0x1000be1cc <+260>: cmp x9, x8
0x1000be1d0 <+264>: b.ne 0x1000be1ec ; <+292>
0x1000be1d4 <+268>: mov x0, x20
0x1000be1d8 <+272>: ldp x29, x30, [sp, #0xb0]
0x1000be1dc <+276>: ldp x20, x19, [sp, #0xa0]
0x1000be1e0 <+280>: ldp x22, x21, [sp, #0x90]
0x1000be1e4 <+284>: add sp, sp, #0xc0
0x1000be1e8 <+288>: ret
0x1000be1ec <+292>: bl 0x1000d9310 ; symbol stub for: __stack_chk_fail
(lldb) register read
General Purpose Registers:
x19 = 0x00006000036c65d0
x20 = 0x000000010019e824 "consumer-frame-show"
x21 = 0x00006000015ac2a0
x22 = 0x00000001301b9850
x23 = 0x0000000000000438
x24 = 0x00000001301b9838
x25 = 0x0000000129691990
x26 = 0x0000000170142b38
x27 = 0x000000012ace7e30
x28 = 0x00006000036c65d0
fp = 0x0000000170142970
sp = 0x00000001701428c0
pc = 0x00000001000be12c libmlt-7.7.dylib`mlt_events_fire + 100
21 registers were unavailable.
(lldb) x/s $x3
error: invalid start address expression.
error: address expression "$x3" evaluation failed
(lldb) x/128bx $x0
error: invalid start address expression.
error: address expression "$x0" evaluation failed
(lldb) x/s $x20
0x10019e824: "consumer-frame-show"
(lldb) x/gx $sp
0x1701428c0: 0x000000010019e824
(lldb) register read --all
General Purpose Registers:
x19 = 0x00006000036c65d0
x20 = 0x000000010019e824 "consumer-frame-show"
x21 = 0x00006000015ac2a0
x22 = 0x00000001301b9850
x23 = 0x0000000000000438
x24 = 0x00000001301b9838
x25 = 0x0000000129691990
x26 = 0x0000000170142b38
x27 = 0x000000012ace7e30
x28 = 0x00006000036c65d0
fp = 0x0000000170142970
sp = 0x00000001701428c0
pc = 0x00000001000be12c libmlt-7.7.dylib`mlt_events_fire + 100
w19 = 0x036c65d0
w20 = 0x0019e824
48 registers were unavailable.
Floating Point Registers:
v8 = {0x00 0x00 0x70 0x42 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
v9 = {0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0x3f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
v10 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
v11 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
v12 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
v13 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
v14 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
v15 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
fpsr = 0x0000001b
fpcr = 0x00000000
s8 = 60
s9 = 0
s10 = 0
s11 = 0
s12 = 0
s13 = 0
s14 = 0
s15 = 0
d8 = 5.5070349750880969E-315
d9 = 1
d10 = 0
d11 = 0
d12 = 0
d13 = 0
d14 = 0
d15 = 0
72 registers were unavailable.
Exception State Registers:
3 registers were unavailable.
(lldb) x/s 0x1000da929
0x1000da929: "list:%s"
(lldb) register read sp
sp = 0x00000001701428c0
(lldb) expr unsigned long x0 = $sp + 8
warning: could not execute support code to read Objective-C class data in the process. This may reduce the quality of type information available.
(lldb) x/128bx x0
error: invalid start address expression.
error: address expression "x0" evaluation failed
(lldb) x/gx $sp
0x1701428c0: 0x000000010019e824
(lldb)
Tested 2 times now and both went ok, so guess is the issue is fixed in shotcut 24.11.17?