mirror of
https://git.ffmpeg.org/ffmpeg.git
synced 2026-10-24 02:09:03 +03:00
60204fe890
A version 2 SoundDescription carries the sample rate as a double, so the
muxer is asked for a rate that does not fit the legacy 16.16 field and
empty_moov places the description ahead of mdat, which puts the double at
a fixed offset of the generated file. run_with_patched_temp then replaces
it, so these tests need no sample either.
Measured with libavformat/mov.c restored from the parent of 3be6c2d943,
i.e. with the double converted before being checked, and these tests kept
in place:
fate-mov-stsd-v2-sample-rate-nan fails (reports -2147483648)
fate-mov-stsd-v2-sample-rate-overflow fails (reports -2147483648)
fate-mov-stsd-v2-sample-rate-negative passes
fate-mov-stsd-v2-sample-rate-zero passes
The first two compare the diagnostic rather than only the exit status:
on this x86-64 build the conversion happens to produce INT_MIN, which the
later sample_rate check rejects as well, so the rejection alone does not
show which check fired, and the value it reports is undefined anyway.
The zero test fixes the opposite direction. Zero must stay accepted,
because mov_finalize_stsd_codec() then falls back to the media timescale;
a check rejecting it as invalid would break that fallback.
The generator decodes the lavfi input device's s16 output, which the
device describes with the native-endian PCM codec id, so the decoder
dependency follows the host endianness.
Signed-off-by: Furkan Efe Can <caglarf646@gmail.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>