The eight positions of the eight-row window are the same walk for every
vertical tail, and calc_all already carries it. The wider weighted tails stay
as they are: calc_all2 fixes its window to v16..v31, so handing them over means
moving their accumulators and weight vectors out of that range first.
No functional changes.
The unweighted step macros in this file let a post-indexed load walk the
intermediate plane, while these weighted steps loaded a row and then advanced
sp with a separate add. Fold the advance into the load.
The step macro now names its row register without a width letter, which is
what the next change needs in order to drive these tails from calc_all.
Cover ID3v2.3 and ID3v2.4 with a chapter title long enough that a plain
size and a synchsafe size differ. Print the CHAP size bytes, declared and
actual tag lengths, chapter counts, titles and timings for FATE to compare
against its reference output.
Also give the first embedded text frame an oversized length and verify
through the reference that both chapters and their timings survive.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
ID3v2.3 stores a frame size as a plain 32-bit integer. ID3v2.4 stores it
as a synchsafe integer. write_chapter() always wrote the plain form, and
read_chapter() always read it that way. Once an embedded text frame
reached 128 bytes, the size no longer fitted and the chapter was dropped.
Write the CHAP header with the same version rule as other frames. Read an
embedded frame with that rule, and keep the chapter when a subframe size
does not fit.
Fixes: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/25357
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
The generated MPEG-2 video depends on the automatic slice thread count.
Use a single video encoder thread so CPU availability cannot change the
fixture. The current master seek reference does not sample the packets
whose sizes expose this difference on release/9.0, so it is unchanged.
Validated fate-seek-hls with freshly generated input three times each
under CPU affinity masks containing one, two, and eight CPUs.
Related-to: #24579
Assisted-by: Fairy
A queued display entry holds a decode surface index, not a copy of its
pixels. Parsing another packet can reuse that surface before the entry
is mapped, associating a later image with the queued timestamp. The
queue occupancy check does not protect individual surface lifetimes.
Consume queued output before fetching another packet. In particular,
this drains both deinterlaced fields before submitting further input.
A generated 120-frame interlaced H.264 stream decoded with -deint bob
produces 157 incorrect images out of 240 on an RTX 5090. With this guard,
all 240 images match the software-decoded, spatially constant source
frames, and diagnostic logging no longer observes queued surface reuse.
Based on the candidate fix provided by hayateppp in issue #25210.
The original report's private inputs remain untested here.
Assisted-by: Fairy
When the bottom-left (or top-right) reference samples cross the picture
edge, the part outside the picture was filled from the last in-picture
sample before the constrained_intra_pred substitution, which only runs up
to the picture edge. If that sample belongs to an inter CU, its raw value
stayed in the out-of-picture part instead of the substituted one
(8.4.4.2.2), and the prediction no longer matched the encoder or HM.
Seen with x265 at 1080p, 64x64 CTBs and constrained intra prediction:
TUs in the partial bottom CTB row next to inter CUs mismatch from there
on.
h264_nvenc, hevc_nvenc and av1_nvenc had no entry in encoders.texi.
Document them in one section: hardware input and devices, the generic
options they map, the options common to all three (presets and tuning,
rate control, lookahead, AQ and B-frames, SEI and side data), and the
options specific to each codec.
Option names, named values, ranges and defaults follow the AVOption
tables in nvenc_h264.c, nvenc_hevc.c and nvenc_av1.c, checked against
ffmpeg -h encoder=<name> from a build against nv-codec-headers 13.1.
Options that depend on the SDK version state the version they need.
Signed-off-by: lusoris <lusoris@proton.me>
The whisper filter exposes segment timestamps and text in JSON but omits the language selected by whisper.cpp. Clients consuming multilingual transcripts cannot distinguish the language of each transcription chunk without detecting it again.
Read whisper_full_lang_id() after each successful transcription and include its language code in JSON segments when available. This leaves the configured language and audio-frame metadata unchanged. Document that the code applies to the whole chunk, not to individual segments.
Tested with a minimal --enable-whisper build, make fate (without external SAMPLES), and a local WAV transcription using a multilingual tiny model.
Signed-off-by: Stefan Singer <stefan.singer@quartr.se>
Nellymoser expects the caller to set the samplerate, as it
doesn't read it from the bitstream. However the generic check
for this is bypassed as it has the AV_CODEC_CAP_CHANNEL_CONF
capability because it does set the channel configuration,
however that cap also bypasses the generic samplerate check.
This is mostly harmless as nellymoser doesn't care about the
samplerate, but since f566032bfd it would cause an AVERROR_BUG
to be returned to the caller, so better reject it outright in
the decoder.
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
EXT-X-START may appear in both Master and Media Playlists (RFC 8216
4.3.5.2). Parsing it allocated a Media Playlist, so a Master Playlist
carrying it before its EXT-X-STREAM-INF entries was rejected since
0e6eef3551.
Record the offset while parsing and apply it once the playlist type is
known. A value from a Master Playlist applies to all its Media
Playlists, which then ignore their own, as RFC 8216 4.3.5 recommends.
Defer EXT-X-ENDLIST the same way, so that it is not lost when it
precedes the first tag allocating the Media Playlist.
A Master Playlist carrying EXT-X-START before its variants is rejected
with "Master Playlist tag found in a Media Playlist", as recorded in the
master-start references.
The media-start-endlist and master-media-start cases record behaviour
that must be kept: an EXT-X-ENDLIST following EXT-X-START, and a start
offset carried only by a Media Playlist.
Parse a playlist, then optionally a Media Playlist into the first
playlist it declared, as hls_read_header() does, and print the parsed
playlists with their finished state and EXT-X-START offset.
The nsamples_max doubling can overflow int for an accepted delay, causing an undersized RDFT and an out-of-bounds write during kernel generation. Compare in int64_t so excessive delays take the existing error path.
Add a FATE check for the reported delay.
Fixes: #24344
Reported-by: yijan4845
Assisted-by: Fairy
Cast each probed symbol to intptr_t and store it in a static volatile
object instead of casting it to long in a wrapper function whose address
main() masks. The volatile stores keep the references under LTO and
intptr_t avoids the pointer truncation warnings on LLP64 targets
(-Wpointer-to-int-cast). Also deduplicate it with check_host_lib.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
If the pixel format is a hardware one, components will be unset, and we will
end up writing an invalid pixi box.
Signed-off-by: James Almer <jamrial@gmail.com>
Widths 4 to 64 at 8 bit, with the height a runtime argument as in the
C code. Factoring 2^min(logw,logh) out of the numerator keeps the whole
kernel in words: the largest intermediate is 32704, when max(w,h) is 64.
The term that is linear in y is carried as a running accumulator, so a
row costs one pmullw and three shifts per column group. Widths 32 and 64
run two column groups per pass and write a row with a single 32 byte
store.
checkasm --bench on a Core Ultra 7 155H:
vvc_pred_planar_4x4_8_c: 63.0
vvc_pred_planar_4x4_8_avx2: 20.3 ( 3.10x)
vvc_pred_planar_8x8_8_c: 216.7
vvc_pred_planar_8x8_8_avx2: 35.6 ( 6.09x)
vvc_pred_planar_16x16_8_c: 966.4
vvc_pred_planar_16x16_8_avx2: 80.3 (12.03x)
vvc_pred_planar_32x32_8_c: 3032.7
vvc_pred_planar_32x32_8_avx2: 251.5 (12.06x)
vvc_pred_planar_64x64_8_c: 10389.9
vvc_pred_planar_64x64_8_avx2: 967.1 (10.74x)
Covers pred_dc, pred_planar, pred_v, pred_h, pred_mip and both
pred_angular functions for every block shape from 4x4 to 64x64 at 8, 10
and 12 bit. Only pred_planar has asm so far, added in the next commit;
the other checks are skipped until there is asm for them.
This is the test from #22808, squashed. Changes from it: top_buf and
left_buf are sized for 16 bit samples, 778 bytes rather than 405, which
randomize_buffers() overran; bit_depth is declared in its loop;
mode_category is always set; top and left are filled independently, so
swapping the edges fails; pred_planar is tested down to a height of 1,
which ISP splits and chroma produce.
Co-authored-by: Marcos Ashton Iglesias <marcosashiglesias@gmail.com>
set_sps() with a NULL SPS released s->vps before returning, also when only
a non-base layer was cleared while the base layer keeps decoding. The next
base-layer frame then dereferenced the NULL VPS in ff_hevc_is_alpha_video().
Release s->vps only when a new SPS is installed alongside it.
Assisted-by: Fairy
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
A bottom-up software frame, as vflip produces, was handed to
cuMemcpy2DAsync() with its negative linesize as the pitch and copy
width, which the driver rejected, so uploading or downloading such a
frame failed.
The device only copies rows upwards through memory, so transfer such a
frame through a top-down copy of it in a transfer buffer.
Fixes: ogLupSp7oZ6D
Found-by: Joshua Rogers <joshua.rogers@aisle.com>
Assisted-by: Claude
The frames a filter in front of hwupload_cuda produces are allocated
with av_hwframe_get_transfer_buffer(), so that the upload reads from
memory the device transfers directly from.
Assisted-by: Claude
The device transfers directly to and from page-locked host memory,
while pageable memory is copied through a buffer of the driver.
Pageable memory remains in use when page-locked memory cannot be
allocated and with ffnvcodec headers that lack cuMemHostAlloc().
As a page-locked source is read by the device after the upload
returns, uploads now wait for the transfer to complete, like downloads.
ffmpeg -hwaccel cuda -i hevc.mp4 -f null - on a RTX 5090, mean of 10
runs: 1080p 1773 -> 1855 fps, 2160p 497 -> 533 fps, 4320p 112 -> 124 fps.
Assisted-by: Claude
A destination frame without buffers was allocated anew for every
download. For large frames the allocation costs more than the
transfer.
ffmpeg -hwaccel cuda -i hevc.mp4 -f null - on a RTX 5090, mean of 10
runs: 2160p 390 -> 497 fps, 4320p 33 -> 112 fps, 1080p unchanged at
1772 fps.
Assisted-by: Claude
It allocates the buffers of a software frame used for a transfer to or
from a hardware frames context out of a pool kept by that context.
Assisted-by: Claude
ff_frame_get_video_buffer() lays a video frame out like
av_frame_get_buffer() does, but takes the buffer from a callback, so
that the memory can come from a pool or from a device specific
allocator.
Assisted-by: Claude
During USAC decoding (ff_aac_usac_decode_frame), configuration elements
can be mapped and instantiated via che_configure(). For newly allocated
ChannelElement structs, che_configure calls sbr_ctx_alloc_init() which
dynamically allocates ac->che[type][id]. However, che_configure did not
subsequently map the output pointer of the nested SingleChannelElement
elements back to their statically-sized internal ret_buf arrays, causing
a null pointer dereference during IMDCT windowing.
The fix explicitly initializes these pointers following allocation.
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
The weighted narrowing after the horizontal filter was repeated at every
width. Sharing one stage at a time rather than a whole block at a time
keeps the serial sqxtn/sqxtn2/sqxtun chain of a block from stalling an
in-order core.
MediaTek decoders report a default crop rectangle in the initial output
format, and the workaround stopped reading the "crop" rectangle from
them on the NDK path so that the default did not reach the codec
context. The initial format no longer sets the crop rectangle of the
codec context, while the workaround also discards the correct rectangle
these decoders report with INFO_OUTPUT_FORMAT_CHANGED, which leaves the
frames at the full width and height of the output buffers.
This reverts commit 7fe9d12f25.
Until the codec signals INFO_OUTPUT_FORMAT_CHANGED, MediaCodec returns
the output format set up at configure time. The decoder parsed that
format right after start() and copied its crop rectangle, display size
and color description into the codec context, although at that point
the codec has not decoded anything and these fields hold its defaults.
For a 1920x1080 HLG stream, c2.xring.hevc.decoder reports the crop
rectangle Rect(0, 0, 175, 143) and BT.601 SDR color there, and MediaTek
decoders report rectangles such as Rect(0, 0, 318, 238). Callers reading
the codec context after avcodec_open2() got 176x144 or 319x239 and a
wrong color description instead of the stream properties.
Keep the values set by the caller until the codec signals a format
change. The pixel format is still taken from the initial format, as it
reflects the configuration. If the first output buffer arrives without
a format change, the initial format describes the decoded frames and is
applied at that point.
0830e9116f added pthread_setcancelstate() and the PTHREAD_CANCEL_*
values for the udp receive thread, which is no longer cancelled and
does not call them. No other file refers to them.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
