Kostya Shishkov <[email protected]> writes:
> diff --git a/libavcodec/dsputil.c b/libavcodec/dsputil.c
> index d318601..039cf0b 100644
> --- a/libavcodec/dsputil.c
> +++ b/libavcodec/dsputil.c
> @@ -1280,16 +1280,16 @@ static void wmv2_mspel8_h_lowpass(uint8_t *dst,
> uint8_t *src, int dstStride, int
> }
>
> #if CONFIG_RV40_DECODER
> -static void put_rv40_qpel16_mc33_c(uint8_t *dst, uint8_t *src, int stride){
> +void ff_put_rv40_qpel16_mc33_c(uint8_t *dst, uint8_t *src, int stride){
> put_pixels16_xy2_8_c(dst, src, stride, 16);
> }
> -static void avg_rv40_qpel16_mc33_c(uint8_t *dst, uint8_t *src, int stride){
> +void ff_avg_rv40_qpel16_mc33_c(uint8_t *dst, uint8_t *src, int stride){
> avg_pixels16_xy2_8_c(dst, src, stride, 16);
> }
> -static void put_rv40_qpel8_mc33_c(uint8_t *dst, uint8_t *src, int stride){
> +void ff_put_rv40_qpel8_mc33_c(uint8_t *dst, uint8_t *src, int stride){
> put_pixels8_xy2_8_c(dst, src, stride, 8);
> }
> -static void avg_rv40_qpel8_mc33_c(uint8_t *dst, uint8_t *src, int stride){
> +void ff_avg_rv40_qpel8_mc33_c(uint8_t *dst, uint8_t *src, int stride){
> avg_pixels8_xy2_8_c(dst, src, stride, 8);
> }
> #endif /* CONFIG_RV40_DECODER */
Is there no way to remove these from dsputil.c entirely?
> diff --git a/libavcodec/rv34dsp.h b/libavcodec/rv34dsp.h
> new file mode 100644
> index 0000000..3784fab
> --- /dev/null
> +++ b/libavcodec/rv34dsp.h
[...]
> +typedef struct RV34DSPContext {
> + /* rv30 functions */
> + qpel_mc_func put_rv30_tpel_pixels_tab[4][16];
> + qpel_mc_func avg_rv30_tpel_pixels_tab[4][16];
> +
> + /* rv40 functions */
> + qpel_mc_func put_rv40_qpel_pixels_tab[4][16];
> + qpel_mc_func avg_rv40_qpel_pixels_tab[4][16];
> + h264_chroma_mc_func put_rv40_chroma_pixels_tab[3];
> + h264_chroma_mc_func avg_rv40_chroma_pixels_tab[3];
> +} RV34DSPContext;
I'm a bit confused by the split into rv30dsp, rv40dsp and rv34dsp.
Couldn't some of these functions use the same pointer with different
initialisation based on the codec instead of choosing one or the other
per MB?
--
Måns Rullgård
[email protected]
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel