:: Re: [Frei0r] [PATCH] Optimize the b…
Top Page
Delete this message
Reply to this message
Author: jb
Date:  
To: Minimalistic plugin API for video effects
Old-Topics: Re: [Frei0r] [PATCH] Optimize the balanc0r plugin using SSE2
Subject: Re: [Frei0r] [PATCH] Optimize the balanc0r plugin using SSE2
On Saturday 15 September 2012 09:30:05 Dan Dennedy wrote:
> On Sat, Sep 15, 2012 at 6:43 AM, salsaman <salsaman@???> wrote:
> > On Sat, Sep 15, 2012 at 7:48 AM, Steinar H. Gunderson
> >
> > <sgunderson@???> wrote:
> >> On Fri, Sep 14, 2012 at 10:47:23AM -0700, Dan Dennedy wrote:
> >>> Thank for you trying to help. To other committers, please do not apply
> >>> this because there is uncertainty about its correctness in another
> >>> thread. In that case, perhaps this should only be changed to somehow
> >>> indicate it is deprecated. Plus...
> >>
> >> Sorry, I didn't see the rest of your comments until now.
> >>
> >>>> +#ifdef __SSE2__
> >>>
> >>> where is that defined? Looks gcc-specific but also in clang, but is it
> >>> safe or dependent on some recent version of clang? I know some people
> >>> have submitted patches to frei0r for msvc. What about that compiler?
> >>
> >> GCC sets it if it knows compile-time that your CPU supports SSE2;
> >> for instance, if compiling for 64-bit, or if -msse2 is given.
> >> I don't know what MSVC or ICC does, but I couldn't find offhand a
> >> define for the same thing.
> >>
> >> The intrinsics used are the standard Intel intrinsics for SSE2, which as
> >> far as I know are supported across GCC/Clang/ICC/MSVC.
> >>
> >>> I guess it is not too big of deal if last few pixels are skipped when
> >>> (width * height) is not a multiple of 4.
> >>
> >> If it's not a multiple of 4, the last few pixels will be done by the
> >> scalar
> >> loop below.
> >
> > Shouldn' t be necessary, since the frei0r spec states x and y
> > dimensions must be multiples of 8 pixels, but if it does no harm then
> > you might as well leave it in.
>
> oh yeah, I remember that stupid requirement now because because MLT is
> too flexible to be adhere to it. So, I have to try to be on the
> lookout for removing those limitations in the frei0r plugins.


In case someone can look at this issue, the frei0r scale0tilt effect crashes
MLT when using height that is not a multiple of 8 (*), like for example when
using the MLT square_ntsc_wide profile:

melt -profile square_ntsc_wide color:red -attach frei0r.scale0tilt "Scale
X=0.2" "Scale Y=0.2"

(*) As reported in Kdenlive bug tracker:
http://kdenlive.org/mantis/view.php?id=2827

Thanks & regards,
jb

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb2ab9b40 (LWP 4011)]
0xb2e09eb6 in scale_uint8_x_4_y_generic_sse2 () from
/usr/local/lib/libgavl.so.1
(gdb) thread apply all bt

Thread 4 (Thread 0xb2ab9b40 (LWP 4011)):
#0  0xb2e09eb6 in scale_uint8_x_4_y_generic_sse2 () from 
/usr/local/lib/libgavl.so.1
#1  0xb2daf0b1 in gavl_video_scale_context_scale () from 
/usr/local/lib/libgavl.so.1
#2  0xb2dab939 in gavl_video_scaler_scale () from /usr/local/lib/libgavl.so.1
#3  0xb3b395c1 in f0r_update (instance=instance@entry=0xb21053c0, 
time=time@entry=0, 
    inframe=0xb1c7d030, outframe=0xb19d9030)
    at /home/two/downloads/git/frei0r/src/filter/scale0tilt/scale0tilt.c:305
#4  0xb7fb5eeb in process_frei0r_item (service=service@entry=0x81ac720, 
position=0, time=0, 
    prop=prop@entry=0x81ac720, this=this@entry=0xb2100d00, 
image=image@entry=0xb2ab9344, 
    width=width@entry=0xb2ab9328, height=height@entry=0xb2ab932c) at 
frei0r_helper.c:150
#5  0xb7fb5485 in filter_get_image (this=this@entry=0xb2100d00, 
image=image@entry=0xb2ab9344, 
    format=format@entry=0x81b29d4, width=width@entry=0xb2ab9328, 
    height=height@entry=0xb2ab932c, writable=writable@entry=0) at 
filter_frei0r.c:39
#6  0xb7f8822e in mlt_frame_get_image (self=self@entry=0xb2100d00, 
    buffer=buffer@entry=0xb2ab9344, format=format@entry=0x81b29d4, 
    width=width@entry=0xb2ab9328, height=height@entry=0xb2ab932c, 
writable=writable@entry=0)
    at mlt_frame.c:475