[FFmpeg-devel] [PATCH] tests/fate-run: support both le/be formats on pixfmts

[Muhammad Faiz]

On Mon, Jun 27, 2016 at 3:28 PM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> On Mon, Jun 27, 2016 at 10:12 AM, Muhammad Faiz <mfcc64 at gmail.com> wrote:
>> On Mon, Jun 27, 2016 at 2:59 PM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
>>> On Mon, Jun 27, 2016 at 9:52 AM, Muhammad Faiz <mfcc64 at gmail.com> wrote:
>>>> regardless of the actual supported formats of tested filters
>>>> allowing filters to support only native endian formats
>>>>
>>>> Signed-off-by: Muhammad Faiz <mfcc64 at gmail.com>
>>>> ---
>>>>  tests/fate-run.sh                 |  7 ++++++-
>>>>  tests/ref/fate/filter-pixfmts-lut | 22 ++++++++++++++++++++++
>>>>  tests/ref/fate/filter-pixfmts-pad | 32 ++++++++++++++++++++++++++++++++
>>>>  3 files changed, 60 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
>>>> index c898695..066970c 100755
>>>> --- a/tests/fate-run.sh
>>>> +++ b/tests/fate-run.sh
>>>> @@ -232,7 +232,12 @@ pixfmts(){
>>>>      $showfiltfmts scale | awk -F '[ \r]' '/^OUTPUT/{ fmt=substr($3, 5); print fmt }' | sort >$scale_out_fmts
>>>>      comm -12 $scale_in_fmts $scale_out_fmts >$scale_exclude_fmts
>>>>
>>>> -    $showfiltfmts $filter | awk -F '[ \r]' '/^INPUT/{ fmt=substr($3, 5); print fmt }' | sort >$in_fmts
>>>> +    $showfiltfmts $filter | awk -F '[ \r]' \
>>>> +        '/^INPUT/{ fmt=substr($3, 5);
>>>> +        print fmt;
>>>> +        print gensub(/(be)$/, "le", "g", fmt);
>>>> +        print gensub(/(le)$/, "be", "g", fmt);
>>>> +        }' | sort >$in_fmts
>>>>      pix_fmts=$(comm -12 $scale_exclude_fmts $in_fmts)
>>>>
>>>
>>> This doesn't really test anything new, does it?
>>> Just adds one more scaling step to convert endianness for some filters.
>>
>> No, it doesn't of course.
>> Just for example: a filter support yuv420p10le on LE machine,
>> yuv420p10be on BE machine
>> fate will test both yuv420p10le/yuv420p10be
>
> I would argue it doesn't add anything then but extra runtime, unless
> I'm missing something.
> The endian conversion is lossless, so even if we test LE on a BE
> system the result is still accurate.

Yes, It will be slower. But, in case of filters that support both le/be,
this is required. Checking whether a filter supports native only or
supports both
isn't trivial (for me).

Another nice feature is that if someone decides to support
both le/be, the fate-ref already exists.

Thank's