FFmpeg
Macros | Functions
swscale_unscaled.c File Reference
#include "config.h"
#include "libswscale/swscale.h"
#include "libswscale/swscale_internal.h"
#include "libavutil/aarch64/cpu.h"

Go to the source code of this file.

Macros

#define YUV_TO_RGB_TABLE
 
#define DECLARE_FF_YUVX_TO_RGBX_FUNCS(ifmt, ofmt)
 
#define DECLARE_FF_YUVX_TO_ALL_RGBX_FUNCS(yuvx)
 
#define DECLARE_FF_NVX_TO_RGBX_FUNCS(ifmt, ofmt)
 
#define DECLARE_FF_NVX_TO_ALL_RGBX_FUNCS(nvx)
 
#define SET_FF_NVX_TO_RGBX_FUNC(ifmt, IFMT, ofmt, OFMT, accurate_rnd)
 
#define SET_FF_NVX_TO_ALL_RGBX_FUNC(nvx, NVX, accurate_rnd)
 

Functions

static void get_unscaled_swscale_neon (SwsContext *c)
 
void ff_get_unscaled_swscale_aarch64 (SwsContext *c)
 

Macro Definition Documentation

#define YUV_TO_RGB_TABLE
Value:
c->yuv2rgb_v2r_coeff, \
c->yuv2rgb_u2g_coeff, \
c->yuv2rgb_v2g_coeff, \
c->yuv2rgb_u2b_coeff, \
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32

Definition at line 24 of file swscale_unscaled.c.

#define DECLARE_FF_YUVX_TO_RGBX_FUNCS (   ifmt,
  ofmt 
)
Value:
int ff_##ifmt##_to_##ofmt##_neon(int w, int h, \
uint8_t *dst, int linesize, \
const uint8_t *srcY, int linesizeY, \
const uint8_t *srcU, int linesizeU, \
const uint8_t *srcV, int linesizeV, \
const int16_t *table, \
int y_offset, \
int y_coeff); \
\
static int ifmt##_to_##ofmt##_neon_wrapper(SwsContext *c, const uint8_t *src[], \
int srcStride[], int srcSliceY, int srcSliceH, \
uint8_t *dst[], int dstStride[]) { \
const int16_t yuv2rgb_table[] = { YUV_TO_RGB_TABLE }; \
\
return ff_##ifmt##_to_##ofmt##_neon(c->srcW, srcSliceH, \
dst[0] + srcSliceY * dstStride[0], dstStride[0], \
src[0], srcStride[0], \
src[1], srcStride[1], \
src[2], srcStride[2], \
yuv2rgb_table, \
c->yuv2rgb_y_offset >> 6, \
} \
return srcSliceH
uint8_t
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
static const uint16_t table[]
Definition: prosumer.c:206
#define src
Definition: vp8dsp.c:254
uint8_t w
Definition: llviddspenc.c:38
#define YUV_TO_RGB_TABLE
these buffered frames must be flushed immediately if a new input produces new the filter must not call request_frame to get more It must just process the frame or queue it The task of requesting more frames is left to the filter s request_frame method or the application If a filter has several the filter must be ready for frames arriving randomly on any input any filter with several inputs will most likely require some kind of queuing mechanism It is perfectly acceptable to have a limited queue and to drop frames when the inputs are too unbalanced request_frame For filters that do not use the this method is called when a frame is wanted on an output For a it should directly call filter_frame on the corresponding output For a if there are queued frames already one of these frames should be pushed If the filter should request a frame on one of its repeatedly until at least one frame has been pushed Return or at least make progress towards producing a it should return
int srcW
Width of source luma/alpha planes.

Definition at line 30 of file swscale_unscaled.c.

#define DECLARE_FF_YUVX_TO_ALL_RGBX_FUNCS (   yuvx)
Value:
#define DECLARE_FF_YUVX_TO_RGBX_FUNCS(ifmt, ofmt)

Definition at line 55 of file swscale_unscaled.c.

#define DECLARE_FF_NVX_TO_RGBX_FUNCS (   ifmt,
  ofmt 
)
Value:
int ff_##ifmt##_to_##ofmt##_neon(int w, int h, \
uint8_t *dst, int linesize, \
const uint8_t *srcY, int linesizeY, \
const uint8_t *srcC, int linesizeC, \
const int16_t *table, \
int y_offset, \
int y_coeff); \
\
static int ifmt##_to_##ofmt##_neon_wrapper(SwsContext *c, const uint8_t *src[], \
int srcStride[], int srcSliceY, int srcSliceH, \
uint8_t *dst[], int dstStride[]) { \
const int16_t yuv2rgb_table[] = { YUV_TO_RGB_TABLE }; \
\
return ff_##ifmt##_to_##ofmt##_neon(c->srcW, srcSliceH, \
dst[0] + srcSliceY * dstStride[0], dstStride[0], \
src[0], srcStride[0], src[1], srcStride[1], \
yuv2rgb_table, \
c->yuv2rgb_y_offset >> 6, \
} \
return srcSliceH
uint8_t
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
static const uint16_t table[]
Definition: prosumer.c:206
#define src
Definition: vp8dsp.c:254
uint8_t w
Definition: llviddspenc.c:38
#define YUV_TO_RGB_TABLE
these buffered frames must be flushed immediately if a new input produces new the filter must not call request_frame to get more It must just process the frame or queue it The task of requesting more frames is left to the filter s request_frame method or the application If a filter has several the filter must be ready for frames arriving randomly on any input any filter with several inputs will most likely require some kind of queuing mechanism It is perfectly acceptable to have a limited queue and to drop frames when the inputs are too unbalanced request_frame For filters that do not use the this method is called when a frame is wanted on an output For a it should directly call filter_frame on the corresponding output For a if there are queued frames already one of these frames should be pushed If the filter should request a frame on one of its repeatedly until at least one frame has been pushed Return or at least make progress towards producing a it should return
int srcW
Width of source luma/alpha planes.

Definition at line 64 of file swscale_unscaled.c.

#define DECLARE_FF_NVX_TO_ALL_RGBX_FUNCS (   nvx)
Value:
#define DECLARE_FF_NVX_TO_RGBX_FUNCS(ifmt, ofmt)

Definition at line 86 of file swscale_unscaled.c.

#define SET_FF_NVX_TO_RGBX_FUNC (   ifmt,
  IFMT,
  ofmt,
  OFMT,
  accurate_rnd 
)
Value:
do { \
if (c->srcFormat == AV_PIX_FMT_##IFMT \
&& c->dstFormat == AV_PIX_FMT_##OFMT \
&& !(c->srcH & 1) \
&& !(c->srcW & 15) \
&& !accurate_rnd) \
c->swscale = ifmt##_to_##ofmt##_neon_wrapper; \
} while (0)
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
if(ret)

Definition at line 99 of file swscale_unscaled.c.

#define SET_FF_NVX_TO_ALL_RGBX_FUNC (   nvx,
  NVX,
  accurate_rnd 
)
Value:
do { \
SET_FF_NVX_TO_RGBX_FUNC(nvx, NVX, argb, ARGB, accurate_rnd); \
SET_FF_NVX_TO_RGBX_FUNC(nvx, NVX, rgba, RGBA, accurate_rnd); \
SET_FF_NVX_TO_RGBX_FUNC(nvx, NVX, abgr, ABGR, accurate_rnd); \
SET_FF_NVX_TO_RGBX_FUNC(nvx, NVX, bgra, BGRA, accurate_rnd); \
} while (0)
#define RGBA(r, g, b, a)
Definition: dvbsubdec.c:39
#define SET_FF_NVX_TO_RGBX_FUNC(ifmt, IFMT, ofmt, OFMT, accurate_rnd)

Definition at line 108 of file swscale_unscaled.c.

Referenced by get_unscaled_swscale_neon().

Function Documentation

static void get_unscaled_swscale_neon ( SwsContext c)
static

Definition at line 115 of file swscale_unscaled.c.

Referenced by ff_get_unscaled_swscale_aarch64().

void ff_get_unscaled_swscale_aarch64 ( SwsContext c)

Definition at line 124 of file swscale_unscaled.c.

Referenced by ff_get_unscaled_swscale(), and usePal().