On Monday 01 October 2012 17:16:34 j...@kdenlive.org 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 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 Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
