On Sat, Jan 18, 2020 at 3:04 PM Dan Dennedy <d...@dennedy.org> wrote:
> On Fri, Jan 17, 2020 at 12:59 AM jb <j...@kdenlive.org> wrote: > >> Hi Dan, all, >> >> First, thanks a lot for implementing the much anticipated consumer >> scaling >> feature! Nice way to do it! While testing it, I noticed a problem with >> transitions. >> >> It seems like the "consumer_scale" property is not always properly >> propagated >> to the frames. Because of this, transitions sometimes produce a "full >> size" >> image instead of a correctly scaled result. >> >> Issue is reproducible at least with the "composite", "affine" and >> "qtblend" >> transitions. It seems like the "consumer_scale" value is correct on the >> a_frame but not on the b_frame. >> >> Changing this line (in the mentionned transition code) : >> double resolution_scale = mlt_frame_resolution_scale(b_frame); >> >> to: >> double resolution_scale = mlt_frame_resolution_scale(a_frame); >> >> fixes the issue. > > > You are correct. I fixed it in qtblend and affine. However, composite has > not been updated to use mlt_frame_resolution_scale(). When I looked into > that today, I noticed it that it is already working by simply taking a > ratio of the get_image() width and height arguments over the profile width > and height. This rule was also in transition affine as`(double) *width / > normalised_width;`. Thus, I am thinking about removing > mlt_frame_resolution_scale(), the consumer scale property, and simply > applying this technique everywhere. Moreover, this can be done separately > for width and height to make it slightly more accurate when one dimensions > needs to change slightly more or less than the other in order to enforce a > multiple of 2 or more. What do you think? Is there a situation where this > is not desirable and an explicit scale is necessary? > I decided to drop the frame consumer_scale property and mlt_frame_resolution_scale() in favor of the (request_width / profile_width) approach. I found that when a service needs to disable preview scaling (for example, vidstab) it also needs to communicate that to filters before or after. It could do that by clearing the consumer_scale property on the frame, but why add something that needs to be removed when the information already exists and has a way to communicate: the width and height references in get_image calls. Moreover, this provides the added benefit of independent width and height scaling. There is still a "scale" property on the consumer supported by melt and the xml producer to trigger the usage of two different profiles, but you can remove it in kdenlive for the embedded preview as I have just done for Shotcut. Documentation in the form of a page on the web site is coming soon.
_______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
