Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Fixes: Erroneous HTTP POST instead of HTTP PUT for WebVTT HLS variant playlists.
Signed-off-by: Léon Spaans <leons@gridpoint.nl>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Signed-off-by: James Almer <jamrial@gmail.com>

We can directly get data ptr from tensor, so that extral memory
allocation can be removed.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: out of array access
Fixes: 62467/clusterfuzz-testcase-minimized-ffmpeg_BSF_EVC_FRAME_MERGE_fuzzer-6092990982258688

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: "Dawid Kozinski/Multimedia (PLT) /SRPOL/Staff Engineer/Samsung Electronics" <d.kozinski@samsung.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: index -1 out of bounds for type 'CFrameBuffer [100]'
Fixes: 63877/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FOURXM_fuzzer-5854263397711872

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: Assertion !c->fc->nb_streams failed at libavformat/mov.c:7799
Fixes: 63875/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5479178702815232

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

PGMYUV seems to be always limited range. This was a format originally
invented by FFmpeg at a time when YUVJ distinguished limited from full
range YUV, and this codec never appeared to output YUVJ in any
circumstance, so hard-coding limited range preserves the status quo.

The other formats are explicitly documented to be full range RGB/gray
formats. That said, don't tag them yet, due to outstanding bugs w.r.t
grayscale formats and color range handling.

This change in behavior updates a bunch of FATE tests in trivial ways
(added tagging being the only difference).

When using vf_scale to force a specific output color space, also tag
this on the AVFrame. (Mirroring existing logic for output range)

Move the sanity fix for RGB after the new assignment, to avoid leaking
bogus YUV colorspace metadata for RGB spaces.

No need to write a custom string parser when we can just use an integer
option with preset values. The various bits of fallback logic are wholly
redundant with equivalent logic already inside sws_getCoefficients.

Note: I disallowed setting 'out_color_matrix=auto', because this does
not do anything meaningful in the current code (just hard-codes
AVCOL_SPC_BT470BG fallback).

Alpha planes must always be full range, so complain loudly if fed
limited range grayscale input.

Alpha planes are explicitly full range, even for limited range YUVA
formats. Mark them as such.

The documentation states that invalid entries default to SWS_CS_DEFAULT.
A value of 0 is not a valid SWS_CS_*, yet the code incorrectly
hard-codes it to BT.709 coefficients instead of SWS_CS_DEFAULT.

This was a complete hack seemingly designed to work around a different
bug, which was fixed in the previous commit. As such, there is no more
reason not to do this, as it simply breaks changing color range in
sws_setColorspaceDetails for no reason.

More commonly, this fixes the case of sws_setColorspaceDetails after
sws_getContext, since the latter implies sws_init_context.

The problem here is that sws_init_context sets up the range conversion
and fast path tables based on the values of srcRange/dstRange at init
time. This may result in locking in a "wrong" path (either using
unscaled fast path when range conversion later required, or using
scaled slow path when range conversion becomes no longer required).

There are two way outs:

1. Always initialize range conversion and unscaled converters, even if
   they will be unused, and extend the runtime check.
2. Re-do initialization if the values change after
   sws_setColorspaceDetails.

I opted for approach 1 because it was simpler and easier to reason
about.

Reword the av_log message to make it clear that this special converter
is not necessarily used, depending on whether or not there is range
conversion or YUV matrix conversion going on.

Adds another test that uses the start_duration and stop_duration
options instead of start and stop.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

The check if drawing needs to be initialized and supported formats
should be drawable ones was flawed, as pad_stop/pad_start is only
populated from stop_duration/start_duration after these checks.

To fix that, check the _duration variants as well and for better
readability and maintainability break the check out into its own
helper.

Fixes a regression from 86b252ea
Fix #10621
Signed-off-by: Anton Khirnov <anton@khirnov.net>

We calculated offsets as pairs, but addressed them in the shader
as single float values, while reading them as ivec2s.

Also removes unused code (was provisionally added if cooperative matrices
could be used, but that turned out to be impossible).

Rather than the VkFormatFeatureFlagBits enum
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>

VK_KHR_PORTABILITY_ENUMERATION_EXTENSION_NAME is required on macOS,
and VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR flag should
be set.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>

Texinfo 7.0 produces quite different HTML to Texinfo 6.8. Without
this change, enumerated option flags (i.e. Possible values of x
are...) render as white text on a white background with Texinfo 7.0
and are unreadable. This change removes a style for the selector
`.table .table` which causes the background to turn white for these
elements. As far as I can tell, it is not actually used anywhere in
files generated by Texinfo 6.8.
Signed-off-by: Frank Plowman <post@frankplowman.com>

Resolves trac ticket #10636 (http://trac.ffmpeg.org/ticket/10636).

Texinfo 7.0, released in November 2022, changed the names of various
functions. Compiling docs with Texinfo 7.0 resulted in warnings and
improperly formatted documentation. More old names appear to have
been removed in Texinfo 7.1, released October 2023, which causes docs
compilation to fail.

This commit addresses the issue by adding logic to switch between the old
and new function names depending on the Texinfo version. Texinfo 6.8
produces identical documentation before and after the patch.

CC
https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1938238.html
https://bugs.gentoo.org/916104Signed-off-by: Frank Plowman <post@frankplowman.com>

By intent, and in practice, the "active contributor" criterion applies
to the person authoring the commits, not the one pushing them into the
repository.

Cf.:
* http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-October/316054.html
* http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316618.html

Signed-off-by: James Almer <jamrial@gmail.com>

Mapping to ITU-R BS.2051-3 "Sound System G" and ITU-R BS.1196-8 "Channel
Configuration 20".
Signed-off-by: James Almer <jamrial@gmail.com>

Mapping to ITU-R BS.2051-3 "Sound System F" and ITU-R BS.1196-8 "Channel
Configuration 15".
Signed-off-by: James Almer <jamrial@gmail.com>

When operating on large blocks of data it's common to repeatedly use
an instruction on multiple registers. Using the REPX macro makes it
easy to quickly write dense code to achieve this without having to
explicitly duplicate the same instruction over and over.

For example,

    REPX {paddw x, m4}, m0, m1, m2, m3
    REPX {mova [r0+16*x], m5}, 0, 1, 2, 3

will expand to

    paddw       m0, m4
    paddw       m1, m4
    paddw       m2, m4
    paddw       m3, m4
    mova [r0+16*0], m5
    mova [r0+16*1], m5
    mova [r0+16*2], m5
    mova [r0+16*3], m5

Commit taken from x264:
https://code.videolan.org/videolan/x264/-/commit/6d10612ab0007f8f60dd2399182efd696da3ffe4Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>

Partially fixes ticket #798
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Peter Ross <pross@xvid.org>