Re: Bug with "selected zone" render that only affects non-official builds
Hi Em sáb, 26 de out de 2019 às 17:02, Alistair Riddoch < alridd...@googlemail.com> escreveu: > 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? > I cannot reproduce running Kdenlive and MLT master. 19.08.3 due next month will still rely on MLT 6.16 while the next major release 19.12 will bump to MLT 6.18 (to be release soon). > > 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. > I *think* the stable series are built with MLT 6.16 while the nightly builds run on MLT master... > Al > > 1. https://bugzilla.rpmfusion.org/show_bug.cgi?id=5416 > > On Mon, Oct 14, 2019 at 9:51 PM Alistair Riddoch > wrote: > >> Thanks Vincent, I'll give that a try. >> >> Al >> >> On Mon, Oct 14, 2019 at 8:23 PM Vincent Pinon 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 >>> alridd...@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 >> alridd...@googlemail.com >> http://alistairriddoch.org/ >> > > > -- > Alistair Riddoch > alridd...@googlemail.com > http://alistairriddoch.org/ > -- .1010.r.i.1101|n.o.i.s.1110|i.m.1010.g.1110|مقاومة fsf member #5439 usuario GNU/Linux #471966 |_|0|_| |_|_|0| |0|0|0| http://www.gunga.com.br;>gunga http://www.tempoecoarte.com.br;>tempoecoarte http://www.atelier-labs.org;>atelier-labs http://www.mocambos.net;>rede mocambos
Re: Bug with "selected zone" render that only affects non-official builds
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 wrote: > Thanks Vincent, I'll give that a try. > > Al > > On Mon, Oct 14, 2019 at 8:23 PM Vincent Pinon 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 >> alridd...@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 > alridd...@googlemail.com > http://alistairriddoch.org/ > -- Alistair Riddoch alridd...@googlemail.com http://alistairriddoch.org/
Re: Bug with "selected zone" render that only affects non-official builds
Thanks Vincent, I'll give that a try. Al On Mon, Oct 14, 2019 at 8:23 PM Vincent Pinon 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 > alridd...@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 alridd...@googlemail.com http://alistairriddoch.org/
Re: Bug with "selected zone" render that only affects non-official builds
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: Create or load a project with some clips on the timeline. Define in in-point on the project time line which is _not_ at time 00:00:00. Define an out-point on the project time line which is after the in-point. Open the Render dialog. Select "selected zone". Format does not appear to matter, but I have only tested with WAV and MP4. 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 alridd...@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
Bug with "selected zone" render that only affects non-official builds
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 alridd...@googlemail.com http://alistairriddoch.org/ untitled.mp4 Description: video/mp4 region_rendering_bug_repro_1904.kdenlive Description: application/kdenlive
