On Sat, Nov 10, 2012 at 5:51 AM, j-b-m <[email protected]> wrote:
> On Monday 01 October 2012 17:16:34 [email protected] wrote:
>> >> Ahhh, I finally found the problem! The bug is triggered by an
>> >> optimization
>> >> flag: -O2
>> >>
>> >> When using the build script, we configure MLT with --enable-debug, which
>> >> disables optimization flags. However, when manually compiling MLT not in
>> >> debug mode, the "-O2" flag is set and triggers the bug on my system
>> >> (Ubuntu 12.10, gcc 4.7.2).
>> >>
>> >> I was also able to reproduce the problem on an OpenSuse 12.2 with gcc
>> >> 4.7.1.
>> >>
>> >> Not sure but it looks like with this optimization, the aspect ratios are
>> >> sometimes wrongly rounded, giving for example 1,777777 instead of
>> >> 1,777778.
>> >
>> >Thanks for finding this. My main workstation (based on ubuntu 11.10)
>> >has gcc 4.6.1, and while I usually use --enable-debug, I did not
>> >reproduce it without. However, I am concerned about how your patch
>> >changes some of the math, which seems heavy-handed for a rounding
>> >error. Does it fix other cases of mismatching sample aspect rates? Do
>> >you think I should trust your judgement/testing and apply it?
>>
>> Well, I also have doubts about how exactly the bug is triggered by this
>> optimization flag. My patch also fixes other mismatching sample rates, but
>> I am almost sure that the bug was not there in previous versions of MLT, so
>> before we change anything I want to try to find out which commit broke this
>> stuff. I probably won't have time for this before friday, will let you know
>> as asap.
>
> Ok, I have done some more testing on this issue and I think I have found a
> reasonable patch. As mentioned in my previous posts, I think that some

Yes, that is it! Applied in your name.

> optimizations cause the display aspect ratios of consumer and b_frame to be
> slightly different, and thus we enter the case where b_dar > consumer_dar.
> This case happens for example when trying to play a 16:9 video in a 4:3
> profile.
>
> I think this case is wrongly handled by MLT. I can reproduce the problem like
> this:
>
> 1) create a 16:9 clip:
> melt -profile atsc_1080i_50 color:red out=100 -consumer avformat:red.mp4
>
> 2) try to apply an affine transition on the clip in a 4:3 dv_pal profile:
> melt -profile dv_pal color:blue out=100 -track red.mp4 -transition affine
> geometry="0/0:50%x50%:50%"
>
> In this case, the red clip should be placed in the top left corner and scaled
> to use 50% of the screen, but it does not work correctly, see my screenshot:
> http://kdenlive.org/images/affine_fullhd_inside_pal.png
>
> With my patch, the clip is correctly scaled, see my screenshot:
> http://kdenlive.org/images/affine_fullhd_inside_pal_fixed.png
>
> My patch also fixes the original issue reported in this thread.
>
> I did several tests with various profile combinations and I think it works
> correctly.
>
> regards
> jb
> ________________________________________________________________________________
>
>
>
> diff --git a/src/modules/plus/transition_affine.c
> b/src/modules/plus/transition_affine.c
> index dae81b5..86751a9 100644
> --- a/src/modules/plus/transition_affine.c
> +++ b/src/modules/plus/transition_affine.c
> @@ -492,13 +492,14 @@ static int transition_get_image( mlt_frame a_frame,
> uint8_t **image, mlt_image_f
>                         {
>                                 scale_x = geom_scale_x * ( scale_x == 0 ? 1 :
> scale_x );
>                                 scale_y = geom_scale_x * ( scale_y == 0 ? 1 :
> scale_y );
> +                               scale_y *= b_ar / consumer_ar;
>                         }
>                         else
>                         {
>                                 scale_x = geom_scale_y * ( scale_x == 0 ? 1 :
> scale_x );
>                                 scale_y = geom_scale_y * ( scale_y == 0 ? 1 :
> scale_y );
> +                               scale_x *= consumer_ar / b_ar;
>                         }
> -                       scale_x *= consumer_ar / b_ar;
>                 }
>                 if ( scale )
>                 {
>
>
>
>
>
>
>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Mlt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Reply via email to