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
