Even though you write that you were able to reproduce the problem (and identify the bug in the MLT code) now, I installed to SDK and tried it again. If I run shotcut from the QTCreator in debugging mode it never crashed when changing the speed of a clip (tried it for about 50 times - no chance). If I opened the same project with the shotcut.exe from the official enduser distribution, it crashes very often. Also when shotcut is run in debugging mode from the QTCreator environment, it runs much slower. I did not recompile shotcut, but as far as I understand it, shotcut und the MLT lib in the SDK are exactly the same version as in the enduser distribution, but built with different settings (at least in debug mode). I imagine the problem could be related to the execution speed of the application. If it runs outside of the debugger, it runs faster, so the probability for race condition problems to occur is higher.
In the meanwhile I found a âworkaroundâ how to lower the speed of a clip in shotcut v19.10.20: I found out that shotcut (enduser edition, no debugger attached) doesnât crash when you move the timeline marker out of the selected (red) clip frame (e.g. you move it into the middle of the previous clip which is not selected), then lower the speed of the selected clip. However, in that case the clips following after the selected one (that has now a longer play time), will not automatically move to the right, but are partially overwritten by the prolonged clip. Thus I made a copy of the prolonged clip, used the Undo function once to undo the clip speed change, removed the original clip and then pasted the prolonged clip. Maybe my workaround can somehow be explained with what you have found to be the source of the bug.
There is another interesting thing regarding this issue. Twice, shotcut did not crash in libmlt when lowering the speed of a clip, but in libwinphread-1.dll, in function pthread_mutex_lock() which was called by mlt_properties_get_double() (in conjunction with the â_speedâ param). This time it was an access violation too, I guess the mutex lock pointer passed to pthread_mutex_lock() referred to a no longer valid memory location. Details see attached crash4.txt file.crash4.txt (38.9 KB)
Finally, when trying to reproduce the speed change bug I ran into another problem. Shotcut crashed in producer_avformat.c, line 2785.
There we have the following instruction:
memset( *buffer, 0, *samples * *channels * sizeof_sample);
samples pointed to a negative int value (-6). By multiplying with the rest, the whole third param of memset() becomes negative. As the type of the 3rd param is size_t, which is kind of an unsigned integer, if I am correct, the negative value becomes a large uint, thus memset will most often continue writing zeros after the end of the buffer. I ran in this situation when I split a video, then removed some clips, moved some other clips around, lowered the speed of some others randomly and that quite quickly.