Changes between Version 1 and Version 2 of swscale

Mar 31, 2016, 5:36:57 PM (3 years ago)



  • swscale

    v1 v2  
    2323    - it is specifically OK if this breaks mplayer.
    2424  * some features will disappear
    25     - sws_convertPalette8ToPacked24
     25    - sws_convertPalette8ToPacked24 etc.
    2626    - context caching
    2727    - vector API
    3131  * the "scaled" path becomes dynamic
    3232    - dynamic internal format
    33     - dynamic ordering of operations
     33    - dynamic ordering (chaining) of filters
    3434    - merging of operations (e.g. reading yuv input and yuv2rgb conversion to prevent memory stores) where possible and where it gains significant speed
    3535- simd / platform optimizations
    3636  * these should ideally not be exposed in the common code (i.e. a grep for x86 in libswscale/*.c should be mostly empty)
    3737  * simd should be allowed to set constraints. E.g., over-reading and -writing of buffers should be enabled in some scenarios where that makes the assembly easier to write. This should be conveyed to the user so they can choose fast conversion by having padded buffers, or a slower conversion by not having padded buffers
     38  * fast conversion simd often uses contexts to pass around information, which isn't very portable
     40Things to figure out:
     41- slicing
    209213[10:01am] <michaelni> git log -p --author Arthur
    210214[10:02am] <durandal_1707> I can help with coding if blueprints are there
     216[10:27am] <ubitux> BBB: about assembly, the unscaled path is actually very complex to handle
     217[10:27am] <ubitux> first, it has way too much arguments
     218[10:28am] <ubitux> 2nd, to workaround this, since it's using inline asm in x86, it passes the sws context
     220[10:28am] <ubitux> in which the fields are duplicated and directly readable
     221[10:28am] <BBB> I think we should add that, I hadn’t complained that much about the unscaled optimizations yet, indeed
     222[10:28am] <ubitux> (by offsetting the context with some)
     223[10:28am] <BBB> but some of that code is hideous also
     224[10:29am] <ubitux> (with some +macro)
     225[10:29am] <BBB> yeah I remember
     226[10:29am] <BBB> the fast bilinear scaler is also very “"interesting""
     227[10:29am] <BBB> (it’s fast, I admit)
     228[10:30am] <ubitux> BBB: also slicing
     229[10:30am] <BBB> I have surprisingly few opinions on slicing
     230[10:30am] <BBB> some people seem to hate it, I don’t really care
     231[10:30am] <ubitux> do you know how it's done currently?
     232[10:30am] <BBB> roughly, yes
     233[10:31am] <BBB> I wonder if it isn’t easier if slicing was done internally and externally it just had a “-threads” parameter that users can set
     234[10:31am] <ubitux> it's not threadable slicing, it's just for the destination
     235[10:31am] <BBB> I always thought it was for threading
     236[10:31am] <ubitux> no
     237[10:32am] <BBB> :-P
     238[10:32am] <BBB> well good thing I had no opinion on it I guess
     240[10:32am] <ubitux> apparently it was about some cache locality of some sort
     241[10:32am] <michaelni> btw as slicing is mentioned, theres the use case where the whole image doesnt fit in memory (gimp does that) this may be worth a thought in case of a redesign
     243[10:33am] <ubitux> michaelni: doesn't work by squares?
     244[10:33am] <ubitux> only slices?
     245[10:34am] <ubitux> photoshop works by big blocks (call it tiles/squares/bigblocks/whatever)
     246[10:34am] <michaelni> to clarify we dont support that currently, gimp uses its own scaler
     247[10:34am] <michaelni> i just saw that gimp caching code a long time ago (which used squares)
     248[10:34am] <michaelni> or rectangles dont remember