FFmpeg

mirror of https://github.com/FFmpeg/FFmpeg.git synced 2026-08-12 12:14:38 +00:00

Files

Niklas Haas b01236d5fb swscale/optimizer: try pushing all swizzles towards the output

Now that we can directly promote these to plane swizzles, we generally want
to try pushing them in one direction - ideally towards the output, as in the
case of split subpasses, the output is guaranteed to be planar. (And there
may not even be a read)

Results in a lot of diffs, ranging from the benign, e.g.:

 rgb24 -> bgr48be:
   [ u8 XXXX -> +++X] SWS_OP_READ         : 3 elem(s) packed >> 0
   [ u8 ...X -> +++X] SWS_OP_CONVERT      : u8 -> u16 (expand)
-  [u16 ...X -> +++X] SWS_OP_SWIZZLE      : 2103
   [u16 ...X -> zzzX] SWS_OP_SWAP_BYTES
+  [u16 ...X -> zzzX] SWS_OP_SWIZZLE      : 2103
   [u16 ...X -> zzzX] SWS_OP_WRITE        : 3 elem(s) packed >> 0

 rgb24 -> gbrp9be:
   [ u8 XXXX -> +++X] SWS_OP_READ         : 3 elem(s) packed >> 0
   [ u8 ...X -> +++X] SWS_OP_CONVERT      : u8 -> f32
   [f32 ...X -> ...X] SWS_OP_SCALE        : * 511/255
   [f32 ...X -> ...X] SWS_OP_DITHER       : 16x16 matrix + {0 3 2 5}
   [f32 ...X -> ...X] SWS_OP_MIN          : x <= {511 511 511 _}
   [f32 ...X -> +++X] SWS_OP_CONVERT      : f32 -> u16
-  [u16 ...X -> +++X] SWS_OP_SWIZZLE      : 1203
   [u16 ...X -> zzzX] SWS_OP_SWAP_BYTES
-  [u16 ...X -> zzzX] SWS_OP_WRITE        : 3 elem(s) planar >> 0
+  [u16 ...X -> zzzX] SWS_OP_WRITE        : 3 elem(s) planar >> 0, via {2, 0, 1}

To the clear improvements, e.g.:

 bgr24 -> gbrp16be:
   [ u8 XXXX -> +++X] SWS_OP_READ         : 3 elem(s) packed >> 0
-  [ u8 ...X -> +++X] SWS_OP_SWIZZLE      : 2103
   [ u8 ...X -> +++X] SWS_OP_CONVERT      : u8 -> u16 (expand)
-  [u16 ...X -> +++X] SWS_OP_SWIZZLE      : 1203
   [u16 ...X -> zzzX] SWS_OP_SWAP_BYTES
-  [u16 ...X -> zzzX] SWS_OP_WRITE        : 3 elem(s) planar >> 0
+  [u16 ...X -> zzzX] SWS_OP_WRITE        : 3 elem(s) planar >> 0, via {1, 0, 2}

The only case worth careful consideration is when there are swizzled inputs
that result in unusual plane patterns, e.g.:

 argb -> gbrp9be:
   [ u8 XXXX -> ++++] SWS_OP_READ         : 4 elem(s) packed >> 0
-  [ u8 X... -> ++++] SWS_OP_SWIZZLE      : 1230
-  [ u8 ...X -> ++++] SWS_OP_CONVERT      : u8 -> f32
-  [f32 ...X -> ....] SWS_OP_SCALE        : * 511/255
-  [f32 ...X -> ....] SWS_OP_DITHER       : 16x16 matrix + {0 3 2 5}
-  [f32 ...X -> ....] SWS_OP_MIN          : x <= {511 511 511 _}
-  [f32 ...X -> ++++] SWS_OP_CONVERT      : f32 -> u16
-  [u16 ...X -> ++++] SWS_OP_SWIZZLE      : 1203
-  [u16 ...X -> zzzz] SWS_OP_SWAP_BYTES
-  [u16 ...X -> zzzz] SWS_OP_WRITE        : 3 elem(s) planar >> 0
+  [ u8 X... -> ++++] SWS_OP_CONVERT      : u8 -> f32
+  [f32 X... -> ....] SWS_OP_SCALE        : * 511/255
+  [f32 X... -> ....] SWS_OP_DITHER       : 16x16 matrix + {0 0 3 2}
+  [f32 X... -> ....] SWS_OP_MIN          : x <= {511 511 511 511}
+  [f32 X... -> ++++] SWS_OP_CONVERT      : f32 -> u16
+  [u16 X... -> zzzz] SWS_OP_SWAP_BYTES
+  [u16 X... -> zzzz] SWS_OP_SWIZZLE      : 3120
+  [u16 ...X -> zzzz] SWS_OP_WRITE        : 3 elem(s) planar >> 0, via {1, 2, 0}
     (X = unused, z = byteswapped, + = exact, 0 = zero)

Observe the change from ...X to X..., which is a pattern that doesn't
necessarily have a fast path and would usually end up falling back to the
generic 4-component implementations (rather than the 3-component ones).

That said, this is not a big deal, since we can ultimately re-align the
set of implementations with what's actually needed; once we're done with
plane splitting and so forth.

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>

2026-02-19 19:44:46 +00:00