[FFmpeg-devel] [PATCH] fate: use an even more exotic channel layout mov-mp4-pcm-float test

[Marton Balint]

On Sun, 18 Feb 2024, James Almer wrote:

> On 2/18/2024 3:38 PM, Marton Balint wrote:
>>
>>
>>  On Sun, 18 Feb 2024, James Almer wrote:
>>
>>>  On 2/18/2024 7:45 AM, Marton Balint wrote:
>>>>   The old layout happened to be a native layout and therefore missed some
>>>>   recently fixed layout parsing bugs.
>>>>
>>>>   Signed-off-by: Marton Balint <cus at passwd.hu>
>>>>   ---
>>>>     tests/fate/mov.mak               | 2 +-
>>>>     tests/ref/fate/mov-mp4-pcm-float | 4 ++--
>>>>     2 files changed, 3 insertions(+), 3 deletions(-)
>>>>
>>>>   diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
>>>>   index 4850c8aa94..8d154c8b5b 100644
>>>>   --- a/tests/fate/mov.mak
>>>>   +++ b/tests/fate/mov.mak
>>>>   @@ -187,7 +187,7 @@ fate-mov-mp4-pcm: CMD = transcode wav
>>>>   $(TARGET_PATH)/tests/data/asynth-44100-1.w
>>>>     FATE_MOV_FFMPEG-$(call TRANSCODE, PCM_S16LE, MOV, WAV_DEMUXER
>>>>     PAN_FILTER) \
>>>>                               += fate-mov-mp4-pcm-float
>>>>     fate-mov-mp4-pcm-float: tests/data/asynth-44100-1.wav
>>>>   -fate-mov-mp4-pcm-float: CMD = transcode wav
>>>>   $(TARGET_PATH)/tests/data/asynth-44100-1.wav mp4 "-af
>>>>   aresample,pan=FL+LFE+BR|c0=c0|c1=c0|c2=c0 -c:a pcm_f32le" "-map 0 -c
>>>>  copy
>>>>   -frames:a 0"
>>>>   +fate-mov-mp4-pcm-float: CMD = transcode wav
>>>>   $(TARGET_PATH)/tests/data/asynth-44100-1.wav mp4 "-af
>>>>   aresample,pan=FR+FL+FR|c0=c0|c1=c0|c2=c0 -c:a pcm_f32le" "-map 0 -c
>>>>  copy
>>>>   -frames:a 0"
>>>
>>>  Wouldn't FR+FL+LFE be enough to test this? While also generating a file
>>>  that's realistic.
>>
>>  It depends on what you want to test. With the old code, for FR+FL+LFE,
>>  only the channel order would have been wrong, with FR+FL+FR also the
>>  channel count.
>>
>>  Having the same channel position in the same track is not that
>>  theoretical, at least for MOV I have samples where an additional FR/FL
>>  track is used for Music/Effects. I admit, for MP4 that might be less
>>  common though, and I also admit that using a separate track for it would
>>  be better. But as we know, nothing is ideal in practice...
>>
>>  Nevertheless, I can change the test to FR+FL+LFE if that is preferred.
>
> No, it's ok as is if it tests more things that can potentially regress.

Ok, will apply as is then.

Thanks,
Marton