On Mon, Jun 27, 2016 at 3:53 PM, Muhammad Faiz <mfc...@gmail.com> wrote:
> On Mon, Jun 27, 2016 at 3:28 PM, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
>> On Mon, Jun 27, 2016 at 10:12 AM, Muhammad Faiz <mfc...@gmail.com> wrote:
>>> On Mon, Jun 27, 2016 at 2:59 PM, Hendrik Leppkes <h.lepp...@gmail.com>
>>> wrote:
>>>> On Mon, Jun 27, 2016 at 9:52 AM, Muhammad Faiz <mfc...@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 <mfc...@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
Need someone test this on BE machine
Thank's
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
