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

James Almer jamrial at gmail.com
Sun Feb 18 20:41:18 EET 2024


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.

> 
> Regards,
> Marton
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".


More information about the ffmpeg-devel mailing list