[vlc-devel] [PATCH 1/6] chroma: chain: suggest *->CVPI conversion

[Alexandre Janniaux]

Hi,

This patch as is is probably not the best addition that
could be done to this part of the pipeline, given that it
works well for CVPB -> CVPI in particular, but might not
work, for example, with NV12 -> * as it could add intermediate
steps to VLC_CODEC_CVPX*.

I'm not exactly sure of how this should be handled though,
as it is a platform-specific conversion which shouldn't even
be in a core module.

An idea would be to have the CVPX module suggest the correct
start of the conversion directly, but then it means that CVPX
must try handling an intermediate conversion too, which
complexify the code. However, it would allow a direct
conversion+resize from CVPX to i420, which is quite beneficial
for the transcode pipeline.

What do you think?

Regards,
--
Alexandre Janniaux
Videolabs

On Tue, Jun 09, 2020 at 06:43:55PM +0200, Alexandre Janniaux wrote:
> When generating pictures with VLC_CODEC_CVPX_BGRA as i_chroma, the core
> will add the following conversion:
>
>     CVPB -> BGRA -> I422 -> I420
>
> Instead, by hinting that it could use VLC_CODEC_CVPX_I420, we get the
> following conversion chain:
>
>     CVPB -> CVPI -> I420
>
> Which has the benefit to never use swscale while avoiding an additional
> conversion, and transform the last conversion into only a memory
> mapping.
> ---
>  modules/video_chroma/chain.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/modules/video_chroma/chain.c b/modules/video_chroma/chain.c
> index af110ec761..4fba1bdebc 100644
> --- a/modules/video_chroma/chain.c
> +++ b/modules/video_chroma/chain.c
> @@ -74,6 +74,12 @@ static void EsFormatMergeSize( es_format_t *p_dst,
>      VLC_CODEC_I420_16L \
>
>  static const vlc_fourcc_t pi_allowed_chromas_yuv[] = {
> +
> +#ifdef __APPLE__
> +    /* Conversion from CVPB to CVPI */
> +    VLC_CODEC_CVPX_I420,
> +#endif
> +
>      VLC_CODEC_I420,
>      VLC_CODEC_I422,
>      ALLOWED_CHROMAS_YUV10,
> --
> 2.27.0
>