frei0r plugin for kdenlive about frei0r

[ddennedy]

I do not know anything about the mailing list. It is out of my control. I have not seen this question come up on it. In any case, Kdenlive uses MLT for its frei0r interface, and MLT only uses f0r_get_param_value() to read the default value for a parameter. From then on, it only sets value and does not try support what you are trying to do. In most cases, it is out of scope for an image processing plugin to define a region unless that is its sole purpose because there are other plugins that already do this (define masks via alpha channel), and you should combine effects instead of making some uberffect.

[reneg49]

I see that some "transitions" provide the kind of behavior i'm looking for, but they are implemented as "true" MLT plugins that interact with the main app... pity... thanks for the info!

[reneg49]

Let's say (using my LEFT,TOP,RIGHT,BOTTOM metaphor) I want to specify a width/height ratio (in the GUI) that automatically adjusts the 'other" parameters whenever I modify one. This is like a more intelligent 'SIZE' parameter. I also have a BOOL value that allows me to switch between 2 modes: when OFF, I can select a region on the inframe (I copy inframe to outframe and draw lines on outframe). When ON, my update function ignores the region selection and applies instead a warpperspective (opencv) operation on the selected region that uses the same type of parameters that frei0r.c0rners uses. Since kdenlive resizes all clips to the project resolution before applying effects, the 'normal' way (c0rners) of setting the target region of the warp is difficult to control when the source inframe contains an ROI smaller (or of a different W/H ratio) than the outframe dimensions. In such cases, the positioning of each corner position affects the apparent positions of the others... tedious... especially when tracking. By pre-selecting a source region (from the resized inframe) each 'corner' position is really the same as that of the source, and moving a corner has little effect on the positions of the others. If you want to composite artwork on the video of a book, each corner of the source will match the positions (in perspective) of the corners of the page in the book (with possible tracking, if required). Ideally, the fr0_update function would return a BOOL signifying the need for the app to ignore or get_param_values for each update cycle... I hope this explanation of my need explains that the "multiple effects stack" method is not practical... Thanks for your interest!

…

On Sat, Apr 28, 2018 at 12:37 AM, Dan Dennedy ***@***.***> wrote: I do not know anything about the mailing list. It is out of my control. I have not seen this question come up on it. In any case, Kdenlive uses MLT for its frei0r interface, and MLT only uses f0r_get_param_value() to read the default value for a parameter. From then on, it only sets value and does not try support what you are trying to do. In most cases, it is out of scope for an image processing plugin to define a region unless that is its sole purpose because there are other plugins that already do this (define masks via alpha channel), and you should combine effects instead of making some uberffect. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOIk300PcQFyghQcsH7gMRMUfET1odZ2ks5ts_IggaJpZM4TrONd> .

[ddennedy]

I see. Good explanation. I am thinking about a modification I can make to facilitate this such that reading a MLT property can invoke the f0r_get_param_value() function. I think lack of that is a shortcoming in the MLT binding to frei0r. Be patient, however, as I am busy this week preparing a new release of Shotcut. I will attempt this after that.

[reneg49]

Great news! I noticed, in Kdenlive, that the preview frame rate can drop dramatically when processing frames that are part of a selected clip (highlited). I suppose this as to do with the effect GUI refresh... Could the mechanism for the "f0r_get_param_value() function" you propose only be "active" for highlited clips? this way, it would only be used when the user is actually working on the effect and not for normal update() cycles. I hope this is possible at the frei0r interface level!!! ;-) Thank you very much for your interest!

…

On Mon, Apr 30, 2018 at 12:04 PM, Dan Dennedy ***@***.***> wrote: I see. Good explanation. I am thinking about a modification I can make to facilitate this such that reading a MLT property can invoke the f0r_get_param_value() function. I think lack of that is a shortcoming in the MLT binding to frei0r. Be patient, however, as I am busy this week preparing a new release of Shotcut. I will attempt this after that. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOIk3-YPpGUSgcQMGGjARXvxmUDvuWvdks5ttzYbgaJpZM4TrONd> .

[reneg49]

Hi Dan, I don't want to bother you! I was just wondering if you had enough time to investigate the need/possibility of implementing the feature we talked about. I understand that you must be very busy. I suppose one of the problems is finding a way to activate the f0r_get_param_value() mechanism only when the user is actually modifying a parameter and not because of normal run-time keyframe interpolation... and this without (idealy) imposing modifications to the calling "applications"... You must already have a way of fetching the current values since the GUI gets updated when we "pause" or "stop" preview playback while a clip is "selected" and it's effects are displayed ?? P.S. like my boss would say: "You should be able to do this in half an hour... looks easy..." ;-)

…

On Mon, Apr 30, 2018 at 12:04 PM, Dan Dennedy ***@***.***> wrote: I see. Good explanation. I am thinking about a modification I can make to facilitate this such that reading a MLT property can invoke the f0r_get_param_value() function. I think lack of that is a shortcoming in the MLT binding to frei0r. Be patient, however, as I am busy this week preparing a new release of Shotcut. I will attempt this after that. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOIk3-YPpGUSgcQMGGjARXvxmUDvuWvdks5ttzYbgaJpZM4TrONd> .

[ddennedy]

I started working on this, but I am running into problems with various things including MLT properties animation/keyframes. I can make it work OK (not perfect) only if the MLT property is not using animation. The place where this hooks in does not have certain information such as time position, and it is not necessary to be requesting the image of a frame, which has this info, in order to read MLT properties.

I am not going to add support for this in MLT. You can make your effect a MLT service/plugin.
I am closing this since it is not a frei0r issue. If you make a corresponding MLT issue, then I will not volunteer to work on it. IOW, it will remain open until someone submits an approved pull request.

[reneg49]

I get it. It would have to be one of the true MLT plugin... that are hard to develop... ;-) Would it be possible to develop such an MLT plugin that would only serve as a bridge to a frei0r plugin of the kind I'm talking about? Is that a viable path of research for me to embark upon? I might (in my dreams...) be able to create an MLT service that would "know" the API to frei0r and implement functionalities that "custom" frie0r plugins could utilize...

…

On Thu, May 31, 2018 at 5:46 PM, Dan Dennedy ***@***.***> wrote: I started working on this, but I am running into problems with various things including MLT properties animation/keyframes. I can make it work OK (not perfect) only if the MLT property is not using animation. The place where this hooks in does not have certain information such as time position, and it is not necessary to be requesting the image of a frame, which has this info, in order to read MLT properties. I am not going to add support for this in MLT. You can make your effect a MLT service/plugin. I am closing this since it is not a frei0r issue. If you make a corresponding MLT issue, then I will not volunteer to work on it. IOW, it will remain open until someone submits an approved pull request. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOIk35yM9Hhm0bOkUa3_S7BZes8QEuI3ks5t4GSmgaJpZM4TrONd> .

[reneg49]

I contacted you a few months ago about a way to have a frei0r plugin "modify/set/send" a parameter value back to the calling app. This seemed difficult since the frei0r helper only fetches the values upon initialization (one-shot). You suggested I should try to write a generic "mlt" module to possibly implement the feature "at the base level". I have succeeded in writing a (primitive) plugin in the .../src/modules/opencv/... of the mlt-master that succeeds in having kdenlive display a resizable/moveable rectangle (like the composite transition UI) while the plugin operates on the ROI defined by the rectangle. I still can't find a way to "mlt_properties_set_rect( properties, "rect", pdata->startRect );" after changing some of the values that will percolate all the up to the calling app... Without wasting more of your time, could you give a hint, point to an existing module that does this, etc... I saw modules that "return" values "for display only", but none that actually "act on parameters"...

…

On Thu, May 31, 2018 at 5:46 PM, Dan Dennedy ***@***.***> wrote: I started working on this, but I am running into problems with various things including MLT properties animation/keyframes. I can make it work OK (not perfect) only if the MLT property is not using animation. The place where this hooks in does not have certain information such as time position, and it is not necessary to be requesting the image of a frame, which has this info, in order to read MLT properties. I am not going to add support for this in MLT. You can make your effect a MLT service/plugin. I am closing this since it is not a frei0r issue. If you make a corresponding MLT issue, then I will not volunteer to work on it. IOW, it will remain open until someone submits an approved pull request. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOIk35yM9Hhm0bOkUa3_S7BZes8QEuI3ks5t4GSmgaJpZM4TrONd> .

[ddennedy]

All MLT service properties are available to read by the application. There is no need to "send" or "return". It is up to the application to read them as-needed. The application might need to be modified to read them as-needed or periodically. There is also a way in MLT for an application to receive a signal when a property is changed. However, I would not be surprised if Kdenlive does not use that. I think this is a new use case, which is interesting. I do not work on Kdenlive but rather Shotcut. If you submit your new service as a pull request on the mlt.git then I will take a look at it further in the context of Shotcut. Then, we will have more information to relay to the Kdenlive team.

[reneg49]

Thanks for your quick response. I already use the "property changed" listener in my service. I understand what you mean, that it is the app's responsibility to fetch the values from the service (the equivalent of a listener on the app side)... I will look into the "kdenlive module" code to see if there is a clue... I dont understand why the services don't return a status of some kind (using a pointer passed to the get_image call or some other mean... I suppose it could create a multi-threading nightmare... Thanks again for your help! I'd like to look into Shotcut, but the firm I work for chose kdenlive... :-(

…

On Thu, Jul 19, 2018 at 12:26 AM, Dan Dennedy ***@***.***> wrote: All MLT service properties are available to read by the application. There is no need to "send" or "return". It is up to the application to read them as-needed. The application might need to be modified to read them as-needed or periodically. There is also a way in MLT for an application to receive a signal when a property is changed. However, I would not be surprised if Kdenlive does not use that. I think this is a new use case, which is interesting. I do not work on Kdenlive but rather Shotcut. If you submit your new service as a pull request on the mlt.git then I will take a look at it further in the context of Shotcut. Then, we will have more information to relay to the Kdenlive team. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOIk3yZFmN4jcj1vJWd7VoCcqi5BBiAQks5uIAqEgaJpZM4TrONd> .

[reneg49]

By the way, I've been looking for the code of your "keyframeable volume" for audio tracks... I would like to to use it as a guide for keyframe implementation. Could you please tell me where it is in mlt-master ??? I found a refenrence to it in the normalize/factory.c file, but the code/parameters seem more complex than described in the volume.xml (kdenlive) effect (only a Gain value).

…

On Thu, Jul 19, 2018 at 12:26 AM, Dan Dennedy ***@***.***> wrote: All MLT service properties are available to read by the application. There is no need to "send" or "return". It is up to the application to read them as-needed. The application might need to be modified to read them as-needed or periodically. There is also a way in MLT for an application to receive a signal when a property is changed. However, I would not be surprised if Kdenlive does not use that. I think this is a new use case, which is interesting. I do not work on Kdenlive but rather Shotcut. If you submit your new service as a pull request on the mlt.git then I will take a look at it further in the context of Shotcut. Then, we will have more information to relay to the Kdenlive team. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOIk3yZFmN4jcj1vJWd7VoCcqi5BBiAQks5uIAqEgaJpZM4TrONd> .