[FFmpeg-devel] [FFmpeg-cvslog] swscale/output: add VUYA output support

James Almer jamrial at gmail.com
Mon Aug 8 15:28:32 EEST 2022


On 8/8/2022 5:56 AM, Martin Storsjö wrote:
> On Sun, 7 Aug 2022, James Almer wrote:
> 
>> ffmpeg | branch: master | James Almer <jamrial at gmail.com> | Fri Aug  5 
>> 13:44:16 2022 -0300| [19748132613d1d13f5b6786051910e7375bb3df6] | 
>> committer: James Almer
>>
>> swscale/output: add VUYA output support
>>
>> Signed-off-by: James Almer <jamrial at gmail.com>
>>
>>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=19748132613d1d13f5b6786051910e7375bb3df6 
>>>
>> ---
>>
>> libswscale/output.c                      | 57 
>> ++++++++++++++++++++++++++++++++
>> libswscale/utils.c                       |  2 +-
>> tests/ref/fate/filter-pixdesc-vuya       |  1 +
>> tests/ref/fate/filter-pixfmts-copy       |  1 +
>> tests/ref/fate/filter-pixfmts-crop       |  1 +
>> tests/ref/fate/filter-pixfmts-field      |  1 +
>> tests/ref/fate/filter-pixfmts-fieldorder |  1 +
>> tests/ref/fate/filter-pixfmts-hflip      |  1 +
>> tests/ref/fate/filter-pixfmts-il         |  1 +
>> tests/ref/fate/filter-pixfmts-null       |  1 +
>> tests/ref/fate/filter-pixfmts-pad        |  1 +
>> tests/ref/fate/filter-pixfmts-scale      |  1 +
>> tests/ref/fate/filter-pixfmts-transpose  |  1 +
>> tests/ref/fate/filter-pixfmts-vflip      |  1 +
>> 14 files changed, 70 insertions(+), 1 deletion(-)
> 
> The new tests for vuya fail in all ARM configurations.
> 
> The issue disappears if running with CPUFLAGS=0 - but the issue isn't 
> tied to any specific ARM specific assembly routine, but seems to be 
> triggered by "filterAlign = 2" for the vertical luma filter.
> 
> To reproduce the issue on x86, apply this patch:
> 
> diff --git a/libswscale/utils.c b/libswscale/utils.c
> index 34503e57f4..e70281d74f 100644
> --- a/libswscale/utils.c
> +++ b/libswscale/utils.c
> @@ -1855,11 +1855,11 @@ av_cold int sws_init_context(SwsContext *c, 
> SwsFilter *srcFilter,
>           const int filterAlign = X86_MMX(cpu_flags)     ? 2 :
>                                   PPC_ALTIVEC(cpu_flags) ? 8 :
>                                   have_neon(cpu_flags)   ? 2 : 1;
> 
>           if ((ret = initFilter(&c->vLumFilter, &c->vLumFilterPos, 
> &c->vLumFilterSize,
> -                       c->lumYInc, srcH, dstH, filterAlign, (1 << 12),
> +                       c->lumYInc, srcH, dstH, 2, (1 << 12),
>                          (flags & SWS_BICUBLIN) ? (flags | SWS_BICUBIC) 
> : flags,
>                          cpu_flags, srcFilter->lumV, dstFilter->lumV,
>                          c->param,
>                          get_local_pos(c, 0, 0, 1),
>                          get_local_pos(c, 0, 0, 1))) < 0)
> 
> I.e. hardcode passing filterAlign=2 to initFilter for vLumFilter. When 
> running e.g. fate-filter-pixfmts-vflip with this modification on x86 
> normally, it works, but if one runs the same with CPUFLAGS=0, it fails.
> 
> Thus, something in the vertical scaler fails if the the filter is 
> overaligned; fails only for the vuya format test and nothing else. But 
> the x86 assembly seems to cope with it.
> 
> Can you please have a look?
> 
> // Martin

I sent a patch that fixed what you described for me on x86 (and a 
segfault, even), "[PATCH] swscale/output: fix reading chroma values when 
generating vuya output". Does it also fix arm for you?


More information about the ffmpeg-devel mailing list