SSSE3 is already quite old (introduced 2006 for Intel, 2011 for AMD),
so that the overwhelming majority of our users (particularly those
that actually update their FFmpeg) will be using the SSSE3 versions.
This commit therefore removes the MMX and 3DNOW functions overridden
by them (which don't abide by the ABI) to get closer to a removal
of emms_c.
Also merge the mpegvideoenc_qns_template.c file into the main file.
The 3DNOW functions removed in this commit were the last in the
codebase.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SSSE3 is already quite old (introduced 2006 for Intel, 2011 for AMD),
so that the overwhelming majority of our users (particularly those
that actually update their FFmpeg) will be using the SSSE3 versions.
This commit therefore removes the MMX(EXT) functions overridden
by them (which don't abide by the ABI) to get closer to a removal
of emms_c.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SSSE3 is already quite old (introduced 2006 for Intel, 2011 for AMD),
so that the overwhelming majority of our users (particularly those
that actually update their FFmpeg) will be using the SSSE3 versions.
This commit therefore removes the MMX(EXT) functions overridden
by them (which don't abide by the ABI) to get closer to a removal
of emms_c.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The mc00 versions (i.e. the qdsp functions with no subpixel
interpolation) are just wrappers around their fpel versions.
There are SSE2 versions of these, yet the qpel code only
uses the MMX(EXT) versions. This commit changes this and
also removes the MMX(EXT) versions.
This also allowed to remove ff_avg_pixels16_mmxext,
ff_put_pixels16_mmx.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
CPUs which support SSE2, but not in a fast way (so that
they get the additional AV_CPU_FLAG_SSE2SLOW) are ancient
nowadays (2007 and older), so ignore the distinction between
the two and remove MMX and MMXEXT functions that are now
overridden by SSE2 functions.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
CPUs which support SSE2, but not in a fast way (so that
they get the additional AV_CPU_FLAG_SSE2SLOW) are ancient
nowadays (2007 and older), so ignore the distinction between
the two and remove MMX and MMXEXT functions that are now
overridden by SSE2 functions.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The value of sizeof() is of type size_t which means that
an expression like
src1[i * src_stride1 + 4 * (int)sizeof(pixel)]
will use a very large offset if src_stride1 is sufficiently negative.
It works in practice (because it is correct modulo SIZE_MAX),
but UBSan treats it as error:
libavcodec/hpel_template.c:104:1: runtime error: addition of unsigned offset to 0x7ffdfa0391d8 overflowed to 0x7ffdfa0391cc
Fix this by casting sizeof(pixel) to int.
(This has been uncovered by a checkasm test for the hpeldsp
which will be added in a later commit.)
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit fixes two issues in the documentation:
a) The documentation for {put,avg}_pixels_tab only mentions
widths 16 and 8, although it explicitly mentions that there
are four horizontal blocksizes. This part of the patch
basically reverts e5771f4f37.
b) The restrictions on height don't match the reality. While
most users abide by it, some do not:
i) vp56.c copies a 16x12 block.
ii) indeo3 can copy an arbitrary multiple of four lines
for block widths 4, 8 and 16.
iii) SVQ3 can use block sizes luma block sizes 16x16, 8x16,
16x8, 8x8, 4x8, 8x4 and 4x4 and the corresponding
8x8, 4x8, 8x4, 4x4, 2x4, 4x2 and 2x2 chroma block sizes.
This implies that for widths 2 and 4 height can be two
and is guaranteed to be at least even. For all other widths,
height can be a multiple of four.
Furthermore, a comment for the SVQ3 blocksizes has been added.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It indicates a constant frame size (in samples); yet the documentation
of the MPEGH_DECODER_OUTPUT_INFO structure says that it
"gives information about the currently decoded audio data"
and makes no guarantees about it being constant.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The pointer to the decoder is always set after init has been
called successfully.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The channel count is fixed, so we don't need to allocate
space to hold samples for nonexisting channels. This also
means that the maximum channel count is no longer hardcoded
in the macro.
Also switch to decoder_buffer_size to be samples-based.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is mostly pointless for decoders (only useful for those
codecs for which a floating-point and a fixed-point decoder
exist).
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In case some file has been updated. Generally fate samples shouldn't be
replaced to preserve compatibility with older revisions, but before
merge it may happen that files is replaced.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Suppresses implicit integer conversion narrowing warnings:
warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data
Those implicit conversions are abundant in ffmpeg's code base.
Additionally equivalent warnings are not enabled for GCC/Clang by
default, so they are mostly left unfixed.
Suppress reports about them to reduce noise in MSVC build log.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This commit causes the libjxl decoder wrapper to hold onto the decoded
frame until the trailing metadata after the frame is possibly complete
before it submits the frame. This allows EXIF and other metadata boxes
that occur after the frame is fully rendered to be attached to it as
side data.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Normally, the OH_AVCodec is wrapped inside an AVBuffer
to be freed in its free callback; yet when creating
the AVBuffer fails, the decoder is never destroyed.
Reviewed-by: Zhao Zhili <quinkblack@foxmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When using a literal IPv6 address as hostname, it can contain a Zone ID
especially in the case of link-local addresses. Sending this to the
server in the Host header is not useful to the server and in some cases
servers refuse such requests.
To prevent any such issues, strip the Zone ID from the address if it's
an IPv6 address. This also removes it for the Cookies lookup.
Based on a patch by: Daniel N Pettersson <danielnp@axis.com>
The const here is unnecessary, because everything inside
SECTION_RODATA is automatically const and using it exports
these objects from the object file because const is a macro
in x86inc.asm.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is deprecated and doing so gives warnings from Clang.
Use CODEC_SAMPLEFMTS instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When parsing the RTSP message reason, the whole remainder
after parsing the status code was used, which would lead to
a leading space in the parsed reason string.
Blending onto independent alpha framebuffers is not possible under the
constraints of the supported blend operators. While we could handle
blending premul-onto-premul, this would break if the base layer is YUV,
since premultiplied alpha does not survive the (nonlinear) YUV conversion.
Fortunately, blending independent-onto-premul is just as easy, and works in
all cases. So just force this mode when using a linear intermediate blend
texture, which is always RGBA.
Instead of directly mutating `opts->params`. Avoids any possible leak of
overriden params between invocations of this function, as well as the later
`pl_render_image` during the linear output pass.
This was a regression introduced in 292c1df7c1.
Since we don't know the length of the stts data until after building the
index, since we're generating it, we need to merge any ctts data after,
since otherwise tts_count is set to 0, and no packets will be output.
We can't remove the merge entirely, because uncompressed PCM with
a ctts atom is technically valid (e.g. a constant CTS offset).
This fixes old-style uncompressed PCM demuxing.
Fixes#11490.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
