Thank you Dan for your reply. I completely agree with you - a crop filter should be the first in the chain (and it is, even in my implementation), and the MLT framework should not be changed only because it would be handy for me.
Meanwhile, I searched another way to go ahead: i wrote the "dbvemelt" program, essentialy a cut-down version of melt(1), which has a GUI to see the progress. This program loads an XML, then inspects every clip in the playlist described by the XML, and creates a new playlist. The processing is the same used by the editor when it loads a "project". This dbvemelt should give me more control over the framework behavior. I've not finished to experiment, but I've already found a strange thing: after creating a playlist, which already contains my own crop filter where applicable, the program instantiates an avformat consumer, and passes to it the parameters chosen via the editor (compression, bitrates and so on). Same problem! But the problem goes away if I omit to tell avformat the size of the output video (i.e. omit to set s=WxH). Given that I have full control over my own crop filter, now I am getting totally confused. The filter can both return the dimensions (WxH) it is asked for (by consumer avformat), or decide to change them... but it seems that if avformat is told (via s=property) the final dimensions, again some other component kicks in and makes a mess. Actually it is not clear to me how to manage these things, but I will try to understand better. Have nice day, regards, linuxfan > >melt and the xml module require using the loader producer. The loader >producer is very special and chooses which real producer to use based on >the resource string - configured in loader. dict - as well as adding what >we call normalization (aka conform) filters - configured in loader.ini. >Extremely important filters that loader adds that are not in loader.ini are >image and audio converters to convert image and audio data between services >as needed. However, the API lets you easily bypass this loader producer >when you explicitly pass the name of the service as an argument to the >corresponding factory function. If you do not use loader, then you really >ought to add the conversion filters manually to each producer. > >See mlt_factory_producer() in >https://www.mltframework.org/doxygen/mlt__factory_8c.html#a093871823fdf4dad4aee091e98832586 > >It says "service" is optional and to see about MLT_PRODUCER. Not mentioned >is that this is an environment variable. It is documented under "Related >Pages" of Doxygen docs: >https://www.mltframework.org/doxygen/envvars.html> >And then here is docs about loader producer: >https://mltframework.org/plugins/ProducerLoader/> >Basically, if you want full control as you have done, then you will not be >able to use MLT XML and melt. Sorry, but I will not make changes to make >these to work without the loader producer. You can set the environment >variable MLT_PRODUCER to empty but then xml and melt are essentially >broken. The concept of the loader producer is so heavily integrated into >how all of the mature, established video editors and melt use MLT that I am >unwilling to risk the change. It also goes without saying that MLT is >really only ever used and tested using the loader producer. If you want to >continue to not use the loader producer, then you must create your own way >to serialize, deserialize, and render. > >For the crop filter, this is a source image crop and, by design, must come >before all other filters including the ones that loader adds to >deinterlace, scale, and pad to conform the source to the mlt_profile. The >second instance of the crop filter then provides only the parameters to the >one previously added by loader. There is also a qtcrop filter that fills >the area outside of a shape with a color including alpha. > > >On Sun, Jan 31, 2021 at 1:39 PM linux...@tin.it <linux...@tin.it> wrote: > >> Hi all, >> >> I am writing a video editor using mlt. The editor basically >> edits a playlist, inserts filters, and does preview via a swallowed SDL >> window. When requested, the editor generates an XML file to be fed to >> melt(1). So far so good. >> >> In order to crop clips, I used until now the >> stock "crop" filter; it works well but, in the editor, I have to put >> two instances of it, otherwise the crop is not performed. So, I wrote >> my own crop filter, which crops in-place instead of setting some >> properties and letting another instance of itself to do the work. The >> filter works well when used in the editor ("internal instance") but, >> when used by melt(1), the result is wrong. I am sure my filter does the >> correct job, but it seems the image it receives, to be cropped, gets >> scaled down, even if width and height are correct. >> >> For example, I take >> a 320x240 clip and crop 160 pixels from left. In the editor, the result >> is a 160x240 picture - correct. When using melt, the output written in >> the file (consumer avformat) is correctly 160x240, but the contents are >> the wanted picture 80 pixels wide, padded to the right with 80 blank >> pixels. >> >> It is about a week I am trying to solve. I tried to set frame >> properties in the filter, "resize_width", "resize_height", with all the >> possible values, before and after the cropping - nothing happens, the >> result is always the same. >> >> Then I ran melt with -debug, and saw that a >> swscale filter kicks in and resizes 320 -> 160. Of course, no resizing >> should be done, and in fact this does not happen when I am using my >> interactive editor. Still this does not explain why the final image is >> blank-padded on the right, maybe another unwanted filter kicks in. >> >> My >> question is: why melt uses somewhere a rescale filter, when nobody >> asked for it? How can I just take the original frame, crop/resize it at >> will, and pass it to the consumer (or other filters)? When the >> "pipeline" is constructed in the editor it works well, apparently melt >> does something under the hood which I need to exclude. What should I do >> to make melt replicate the same behavior of the interactive editor? >> >> >> Regards, >> linuxfan >> >> >> >> >> >> _______________________________________________ >> Mlt-devel mailing list >> Mlt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mlt-devel>> > _______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
