Bug with "selected zone" render that only affects non-official builds

Alistair Riddoch alriddoch at googlemail.com
Sat Oct 26 21:01:56 BST 2019


I reported this issue via the rpmfusion bug tracker[1], and sergio released
a patched version of MLT with the two commits suggested here, but it
doesn't appear to have fixed the problem. I ran through the git commits
from v6.16.0 to now to see if I could identify what else was required, but
didn't see anything obvious from the commit messages. Does anyone else have
any state on other patches required to MLT to fix this issue, or do we need
a new release of MLT?

It would be useful to know if the kdenlive Appimages are being built from
MLT head, or selected patches on top of v6.16.0.

Al

1. https://bugzilla.rpmfusion.org/show_bug.cgi?id=5416

On Mon, Oct 14, 2019 at 9:51 PM Alistair Riddoch <alriddoch at googlemail.com>
wrote:

> Thanks Vincent, I'll give that a try.
>
> Al
>
> On Mon, Oct 14, 2019 at 8:23 PM Vincent Pinon <vpinon at kde.org> wrote:
>
>> Le lundi 14 octobre 2019, 19:42:18 CEST Alistair Riddoch a écrit :
>>
>> I have come across a bug which affects rendering a selected zone, but
>> does not occur when using the Appimages downloaded from kdenlive.org. I
>> am uncertain whether to file a bug in the tracker, as I'm guessing it is
>> actually a problem with a dependency. I'll describe it here, and I'm happy
>> to file it properly, and help resolve if that seems appropriate.
>>
>>
>> I'm using Fedora 30 and the bug is present in all the binaries I have
>> built from source since some time during 19.04. I have built from the
>> release labels, from the 19.08 branch, and from head and seen the same
>> problem in each case. The bug is also present in the semi-official rpm
>> package from RPM Fusion. The installed Melt is mlt-6.16.0, and is comon to
>> all recent affected builds.
>>
>>
>> The bug is that when I render a "selected zone" of the project, the
>> output of the render is not the correct length, and doesn't contain the
>> correct range of the project output. Very frequently the output is only 1
>> or 2 frames long, and renders almost instantly, despite the selected zone
>> being much longer.
>>
>>
>> Repro steps:
>>
>>    1. Create or load a project with some clips on the timeline.
>>    2. Define in in-point on the project time line which is _not_ at time
>>    00:00:00.
>>    3. Define an out-point on the project time line which is after the
>>    in-point.
>>    4. Open the Render dialog.
>>    5. Select "selected zone".
>>    6. Format does not appear to matter, but I have only tested with WAV
>>    and MP4.
>>    7. Press "Render to File".
>>
>> Expected Result: The output video is the range of the project selected.
>>
>> Actual Result: The output video is apparently random in length, and not
>> obviously directly related to the selected zone.
>>
>>
>> I attach a project file which is a trivial repro case for the bug, and
>> the mp4 file I got when I tried to render a 2 second zone from the middle
>> of this project. The actual output is 2 frames long, and is not correct for
>> the start of the selected zone.
>>
>>
>> Please let me know if more information is required, or if I can do
>> anything else to help fix the bug.
>>
>>
>> Keep up the good work!
>>
>>
>> Al--
>>
>> Alistair Riddoch
>> alriddoch at googlemail.com
>> http://alistairriddoch.org/
>>
>>
>>
>> Hi Alistair,
>>
>>
>>
>> Try to build MLT from git, I believe it has commits fixing this bug (in
>> June, seen on 19.04 releases, using the new consumer xml tag) :
>>
>> 690d3ed55f98d8e31affb1b5dbc84c6948248099 - Pass the consumer's in/out
>> properties when using movit or multi consumer
>>
>> 434dbcf62048cc1220c425c2adc77697b4d40ffb - Fix multi consumer doesn't
>> correctly handle in point
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Vincent
>>
>
>
> --
> Alistair Riddoch
> alriddoch at googlemail.com
> http://alistairriddoch.org/
>


-- 
Alistair Riddoch
alriddoch at googlemail.com
http://alistairriddoch.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20191026/7e2f8207/attachment.html>


More information about the kdenlive mailing list