Priming samples don't depend on the contents of the first frame passed to the
encoder but rather on encoder configuration, so use dummy vorbis_dsp_state and
vorbis_block with the main encoder vorbis_info to generate a packet we can then
parse to derive the initial padding.
Muxers will now be aware of the initial padding before receiving packets, which
will allow them to write proper container headers during init without any extra
considerations like having to do a second pass or rewrite during write_trailer.
Signed-off-by: James Almer <jamrial@gmail.com>
ff_rate_control_init/uninit() are only called during
codec init or close and no DSP calls happen in these,
so there is no need to reset the floating point state.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The MMX code has been removed in 5ef613bcb0
and MMX was not used for most cpus even before then.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are no MMX functions left in all of libswresample, so checking
for it makes no sense. Notice that configure currently disables x86asm
if mmx is disabled, so the check is also redundant.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Said function has presumably been added in order to check
that we have successfully reset the floating point state
after having violated the ABI/calling convention by not
issuing emms in our MMX DSP routines.
Yet the ability to check this should not have been made public,
because there is no external need for it and because the
function does not even always achieve what its documentation
claims to do: It only works when inline assembly is available.
It should have been implemented in emms.h like emms_c()
(which is where a replacement should be put if there is still
ABI-violating MMX code when av_assert0_fpu() is removed).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Starting with PyTorch 2.6, the hooks API was redesigned so it no longer depends on the device type.
As part of this change, the XPU initialization function was renamed from initXPU() to init().
Add version check to support both old and new LibTorch versions.
Signed-off-by: younengxiao <steven.xiao@amd.com>
When using `dnn_processing` filter with torch backend, FFmpeg hangs indefinitely because no inference is actually performed.
Resolve this problem by add "else" branch for synchronous execution path.
Usage:
ffmpeg -i input.mp4 -vf scale=224:224,format=rgb24,dnn_processing=dnn_backend=torch:model=sr_model_torch.pt:device=cpu output.mp4
Don't just export initial_padding, but also take it into account for timestamps
by adjusting the stream's start_time. Also, export the padding samples in a way
that's actually supported, as currently trailing_padding is unused so no user
will look at it.
For the sake of not reducing coverage and because the lossy tests have reference
files that contain the priming samples, add the skip_manual flags2 to the tests
so we still output them. A new ffprobe call will ensure the demuxer behavior is
tested too.
Signed-off-by: James Almer <jamrial@gmail.com>
Unlike md5, the adler32 hash shows the frames with priming samples, which will
be useful in the following commits.
Signed-off-by: James Almer <jamrial@gmail.com>
This also advertises the supported sample rates/channel layouts.
For ADPCM_IMA_AMV, it actually fixes the advertised channel layouts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We know that this is Dolby Vision Enhancement Layer and while it's not
handled, we can just reduce log spam for this, as it's if fact
recognized.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Sockets of type SOCK_DGRAM don't support listen(), so it was
impossible to read from "unixgram" sockets in ffmpeg.
Signed-off-by: Rost Kurylo <rost.kurylo@netint.ca>
Add support for decoding 42ni and 23ni in mov/mp4.
Note that in24/in32 can be either LE or BE thanks to enda atom,
so this patch leaves the muxer unchanged.
Fixes#21445.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Photoshop documents can contain additional "auxiliary" channels that
don't take part in layer compositing, therefore, using the channel count
to determine the presence of an alpha channel in the merged image is
incorrect. Instead, as per the PSD specification, use the sign of the
layer count (present in the layers and masks section) to determine if
there is an alpha channel, then determine the number of primary channels
using both the presence of the alpha channel and the pixel format.
It is pointless for them given that these values will
be overridden by the decoder lateron anyway.
The only exceptions to this are scenarios where the decoder
actually checks request_sample_fmt or where there are both
fixed- and floating point decoders.
(IMO something like get_format() for audio would be better for
both cases.)
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ch_layouts, sample_fmts and supported_samplerates
are of no use for a decoder, so don't set them.
In this case this fixes an inconsistency:
ch_layouts contained mono and stereo, yet lateron
the AVCodecContext's ch_layout is always populated
with an AV_CHANNEL_ORDER_UNSPEC layout.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is unnecessary for a decoder (the sample fmt is
set lateron during init and the user has no choice
over this (even for the decoders where sample_fmts
contains two entries).
(This also fixes the ADPCM_DECODER macro: It's second
and third parameters were called "name" and "sample_fmts",
yet the second argument always contained the sample fmts.)
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SwsContext.{src,dst}_format is int (but uses enum AVPixelFormat)
values, so the accesses need to be performed using an int
for -fshort-enums support.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In particular, make this code -fshort-enums compatible.
The branch can be optimized away by compilers when
sizeof(enum AVPixelFormat) == sizeof(enum AVSampleFormat).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Return the data in an AVFrame instead. This is what several users
({find,cover}_rect*) want anyway. This also avoids accessing
AVFrame.format (an int) via an enum AVPixelFormat*.
*: This commit actually avoids two frame copies For find_rect:
av_frame_clone() contained an implicit alloc+copy.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also rename it to ff_pixfmt_is_in(). This is more type-safe;
in particular, it is required to support -fshort-enum.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Assemble it already in caf_write_packet(). This has the advantage
of reducing the amount of buffers used; it also allows to avoid
a seek when writing the trailer and avoids function call overhead
(for the avio_w8(); it also reduces codesize).
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: out of array access on resolution change with slices threads
Fixes: VULN-10/poc.ivf
Found-by: Zhenpeng (Leo) Lin from depthfirst
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
