On Mon, Nov 5, 2012 at 10:04 AM, Dan Dennedy <[email protected]> wrote: > On Mon, Nov 5, 2012 at 1:19 AM, j-b-m <[email protected]> wrote: >> On Sunday 04 November 2012 11:52:36 Dan Dennedy wrote: >>> On Mon, Oct 29, 2012 at 11:03 AM, Dan Dennedy <[email protected]> wrote: >>> > On Mon, Oct 29, 2012 at 10:40 AM, j-b-m <[email protected]> >> wrote: >>> > > On Monday 05 March 2012 22:52:01 Dan Dennedy wrote: >>> > >> On Sun, Feb 12, 2012 at 1:12 AM, j-b-m <[email protected]> >> wrote: >>> > >> > On Saturday 11 February 2012 23:09:25 Dan Dennedy wrote: >>> > >> >> On Tue, Feb 7, 2012 at 4:04 PM, Dan Dennedy <[email protected]> >>> > >> >> wrote: >>> > >> >> > On Tue, Feb 7, 2012 at 2:06 PM, j-b-m >>> > >> >> > <[email protected]> >>> > > >>> > > wrote: >>> > >> >> >> On Tuesday 07 February 2012 10:32:24 Dan Dennedy wrote: >>> > >> >> >>> On Tue, Feb 7, 2012 at 10:08 AM, j-b-m >>> > >> >> >>> <[email protected]> >>> > >> > >>> > >> > wrote: >>> > >> >> >>> > Hello. >>> > >> >> >>> > >>> > >> >> >>> > Trying to improve image sequence support in Kdenlive, I >>> > >> >> >>> > discovered >>> > >> >> >>> > that >>> > >> >> >>> > MLT >>> > >> >> >> >>> > >> >> >>> > cannot currently load a sequence with files like this: >>> > >> >> >> (...) >>> > >> >> >>> > >> >> I have a new idea. In addition to the existing scanf-style >>> > >> >> heuristic, >>> > >> >> add a new one where you embed the begin value between the % and the >>> > >> >> 'd'. Then, set the begin property, make a new scanf format string >>> > >> >> based on the length of begin, and run the scanf heuristic again. For >>> > >> >> example, foo%01000d.png becomes begin=1000, and filename becomes >>> > >> >> foo%05d.png. Checks for 'i' and 'u' and other relevant characters >>> > >> >> will >>> > >> >> be supported as well. >>> > >> >>> > >> This is in git now. >>> > >> >>> > >> > Seems like a good idea to me. However we need to keep compatibility >>> > >> > with >>> > >> > older project files. Kdenlive currently uses the following pattern: >>> > >> > >>> > >> > foo%.5d.jpg >>> > >> > >>> > >> > So maybe the new format you proposed should have an extra character >>> > >> > or >>> > >> > something else to let MLT know that it has to do a 2 step >>> > >> > processing.. >>> > >> >>> > >> This should not be necessary because the old mode is tried first and >>> > >> should match old loadable sequences. Also, in the above example >>> > >> processing would stop at the first period, and then a check to ensure >>> > >> the embedded begin value length is greater than 1 will fail. See the >>> > >> git comment if needed and give it a try. >>> > > >>> > > At first I thought it was ok, but in fact the logic fails in some cases >>> > > (see kdenlive issue http://kdenlive.org/mantis/view.php?id=2804 ). For >>> > > example, if you have images named like: >>> > > >>> > > image00.jpg, image01.jpg, image02.jpg, image03.jpg, image04.jpg, (...) >>> > > >>> > > If you want to play the whole sequence, you can do the usual: >>> > > >>> > > melt image%02d.jpg >>> > > >>> > > However it is impossible to start the sequence from image01 or image02. >>> > > We have the "load_sequence2" method to load a sequence from a beginning >>> > > value that expects something like: >>> > > >>> > > foo%1234d.png where 1234 is the beginning number. >>> > > >>> > > But since MLT always tries first to load the image sequence with the >>> > > "load_sequence" method, when doing this >>> > > >>> > > melt image%01d.jpg >>> > > >>> > > MLT tries to find the following images: >>> > > >>> > > image1.jpg, image2.jpg, (...) and will then find the existing >>> > > image10.jpg, >>> > > image11.jpg,... >>> > > >>> > > So instead of playing the sequence from image01, it will start at >>> > > image10 >>> > > which is quite confusing. >>> > > >>> > > I counldn't find an easy way to fix it, and not sure we have the energy >>> > > to fix this but at least you are warned that playing a sequence from a >>> > > certain frame might not always work. >>> > >>> > hmm, yes, I see what you mean. I will see if we can use a query string >>> > to pass init-time properties to these producers. >>> >>> I committed a query string version for pixbuf: >>> melt image%02d.jpg?begin=1 >>> >>> This deprecates the old way of embedding the begin value within a >>> pattern, but that is kept for backwards compatibility. If this works >>> OK, then I will apply the same change to qimage. >> >> Works fine, but at least for me it breaks the producer detection... >> Having a '?' as query string makes MLT unable to find the correct producer. >> Was it always like this? >> >> melt image%02d.jpg?begin=1 >> >> fails, but > > ah, yes, the loader producer checks filename extension, but is not > aware of the query string delimiter. That will be an easy fix.
I fixed that, but there was another issue when using melt on the command line. The "image%02d.jpg?begin=1" is interpreted by melt as a property setting. We could try to bust this up by putting a colon before the equal sign: file:image%02d.jpg?begin=1 Avformat understands the file: protocol scheme, but not most other things and not the image producers. So, at the melt command line you must use the alternate syntax using colon as the query string param key/value delimiter: image%02d.jpg?begin:1 -- +-DRD-+ ------------------------------------------------------------------------------ LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d _______________________________________________ Mlt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mlt-devel
