This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to VTFramesContext as one no longer has to
go through AVHWFramesInternal.
Tested-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Components and pieces are side data specific fields and there's a variable
amount of them.
They also need to be identified in some form, so print a type too.
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Do not propagate the return value of avformat_write_header(),
as it contains the information whether the output had
already been initialized in avformat_init_output(),
but this is set generically; the return value of
FFOutputFormat.write_header is not documented at all
(and is currently ignored if >= 0), but it is more future-proof
to simply return 0 on success.
Reviewed-by: Liu Steven <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is intended to avoid -Wformat= warnings on systems
where %s might not be supported (and also generally emitted
by GCC with -pedantic).
Reviewed-by: Liu Steven <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is undefined behaviour to use a different type for a call
than the actual type of the function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This separates the URL-layer adjacent parts of the code
from the parts that are also usable with custom IO.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to QSVFramesContext as one no longer has to
go through AVHWFramesInternal.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to QSVDeviceContext as one no longer has to
go through AVHWDeviceInternal.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to D3D11VAFramesContext as one no longer has to
go through AVHWFramesInternal.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to DXVA2FramesContext as one no longer has to
go through AVHWFramesInternal.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Some encoders, like flac, propagate updated extradata at the end of encoding
as packet side data. Use it to update the relevant codec_config.
Signed-off-by: James Almer <jamrial@gmail.com>
If it's the primary item, then it's expected to be ready for presentation even
outside of the grid it belongs to.
Signed-off-by: James Almer <jamrial@gmail.com>
Doxygen only associates this comment with "pts_correction_num_faulty_pts",
causing it to display incorrectly.
Signed-off-by: Andrew Sayers <ffmpeg-devel@pileofstuff.org>
Doxygen eats the newline in the first comment, making it harder to read.
Join the lines and add a comma, so source and documentation are equally readable.
Doxygen only associates the second comment with cust_dec.
The comments for cust_dec and cust_tab make perfect sense without it,
so downgrade it to a non-doxygen "//" comment.
The third comment was missed by the command in the previous commit,
because it (correctly but uniquely) doesn't have a trailing comma.
Signed-off-by: Andrew Sayers <ffmpeg-devel@pileofstuff.org>
Use AVHWFramesContext.hwctx instead.
This simplifies access to VDPAUFramesContext as one no longer has
to go through AVHWFramesInternal.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to VDPAUDeviceContext as one no longer has to
go through AVHWDeviceInternal.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
libavcodec/vvc/vvc_inter.c:823:18: runtime error: signed integer overflow: 1426128896 + 1426128896 cannot be represented in type 'int'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior libavcodec/vvc/vvc_inter.c:823:18
Suggested-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The following cases should set bs to 1:
If the prediction modes are not the same.
If both prediction modes are MODE_IBC, but the motion vector delta is larger than 8 of 1/16 pixels.
see 8.8.3.5
How to reproduce it:
vvencapp -i sintel_trailer_2k_1080p24.y4m --preset fast --additional "IBC=1" -o sintel.266
ffmpeg -i sintel.266 -f md5 -
md5 will mismatch
Found-by: 6ws at https://github.com/ffvvc/FFmpeg/issues/187#issuecomment-1962842135
Frame-level side data attributes are printed with the same key/value
structure as packet-level side data attributes, but this is not
reflected in the XSD.
It is only used by ffprobe (once) and ffplay (twice);
inlining it avoids including it unnecessarily into ffmpeg.
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Rebased on top of recently merged fixes (should apply correctly now).
In merged DVD patch, -pgc and -pg options were broken. While these are
rather advanced options, they are the only means to get content for
some strangely authored discs.
Signed-off-by: Marth64 <marth64@proxyid.net>
This makes the code much simpler (especially for adding support
for other instruction set extensions), avoids needing inline
assembly for this feature, and generally is more of the canonical
way to do this.
The CPU feature detection was added in
493fcde50a, using HWCAP_CPUID.
The argument for using that, was that HWCAP_CPUID was added much
earlier in the kernel (in Linux v4.11), while the HWCAP flags for
individual features always come later. This allows detecting support
for new CPU extensions before the kernel exposes information about
them via hwcap flags.
However in practice, there's probably quite little advantage in this.
E.g. HWCAP2_I8MM was added in Linux v5.10 - long after HWCAP_CPUID,
but there's probably very little practical cases where one would
run a kernel older than that on a CPU that supports those instructions.
Additionally, we provide our own definitions of the flag values to
check (as they are fixed constants anyway), with names not conflicting
with the ones from system headers. This reduces the number of ifdefs
needed, and allows detecting those features even if building with
userland headers that are lacking the definitions of those flags.
Also, slightly older versions of QEMU, e.g. 6.2 in Ubuntu 22.04,
do expose support for these features via HWCAP flags, but the
emulated cpuid registers are missing the bits for exposing e.g. I8MM.
(This issue is fixed in later versions of QEMU though.)
Signed-off-by: Martin Storsjö <martin@martin.st>
Andreas Rheinhardt
James Almer
Zhao Zhili
Marth64
Andrew Sayers
Anton Khirnov
Nuo Mi
Niklas Haas
Martin Storsjö