This makes the wav and pcm demuxer demux bigger packets, which is more
efficient.
As a side effect of the bigger packets, audio durations can become less exact
for command lines such as "ffmpeg -i $INPUT -c:a copy -t 1.0 $OUTPUT".
Signed-off-by: Marton Balint <cus@passwd.hu>
- Remove the 1024 cap on the number of samples, for high sample rate audio it
was suboptimal, calculate the low neighbour power of two for the number of
samples (audio blocks) instead.
- Make the function work correctly also for non-pcm codecs by using the stream
bitrate to estimate the target packet size. A previous version of this patch
used av_get_audio_frame_duration2() the estimate the desired packet size, but
for some codecs that returns the duration of a single audio frame regardless
of frame_bytes.
- Fallback to 4096/block_align*block_align if bitrate is not available.
Signed-off-by: Marton Balint <cus@passwd.hu>
All versions of MSVC that support C11 (namely >= v19.27)
also support the restrict keyword, therefore av_restrict
is no longer necessary since 75697836b1.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
h_subpel_filters_inner[i] and h_subpel_filters_outer[i / 2]
belong together and the former allows the range 0..6,
so the latter needs to support 0..3. But it has only three
elements. Add another one.
The value for the last element has been guesstimated
from subpel_filters in libavcodec/vp8dsp.c.
This is also intended to fix FATE-failures with UBSan here:
https://fate.ffmpeg.org/report.cgi?time=20240312011016&slot=ppc-linux-gcc-13.2-ubsan-altivec-qemu
Tested-by: Sean McGovern <gseanmcg@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is accessed via AV_RN64A in ff_simple_idct_put_int32_10bit().
Should fix the UBSan failures in the mpeg4-simple-studio-profile
test here:
https://fate.ffmpeg.org/report.cgi?time=20240312011016&slot=ppc-linux-gcc-13.2-ubsan-altivec-qemu
Reviewed-by: Kieran Kunhya <kierank@obe.tv>
Tested-by: Sean McGovern <gseanmcg@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
HAVE_FAST_UNALIGNED being true does not imply that
one can simply read from any pointer via *(long*).
It is undefined behaviour in case the pointer is not
sufficiently aligned; and even if it is, it is (likely)
a violation of the effective-type rules. Fix both
of these by using the appropriate AV_[RW]N macros.
Also, the current code used sizeof(long) as if this
were the CPU's native arithmetic size, but this is
not true on 64bit Windows. This has been fixed, too.
This affected huffyuv FATE-tests.
Tested-by: Sean McGovern <gseanmcg@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They are incorrect according to [1]. They also share keys with valid
entries, so that it is unspecified which entry bsearch returns
in this case. Fix this by removing the incorrect values.
[1]: https://www.earthdata.nasa.gov/s3fs-public/imported/19-008r4.pdf
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead store all the strings in one continugous string
(with internal \0) and use offsets to access the actual
substrings. This replaces the pointers to the strings
and therefore avoids relocations (and on x64, it actually
shrinks TiffGeoTagNameType by reusing padding to store
the offset field).
This saves 720B of .data.rel.ro and 1080B of .rela.dyn
(containing the relocation records) here while increasing
.rodata by 384B.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
