The AMF hardware decoder exposes color information and HDR side data on
output surfaces, but the decoder previously copied only static avctx
values onto output frames. Read primaries, transfer, range, and profile
from each surface, keep avctx updated, and fall back to cached values
when a field is not signalled on a given frame.
On resolution change, re-create the hw frames context instead of
trying to re-init an already initialized pool.
Attach HDR10 mastering/display metadata when PQ transfer is detected.
Release the AMF HDR metadata buffer after attaching side data.
Split each cue at its inline timestamps and emit every segment as
"{\kf<cs>}<text>", the duration being the segment's own span (next
timestamp minus current); the tag precedes the text so the karaoke fill
runs during the segment. Boundaries are rounded to centiseconds against
the cue start and differenced, so durations telescope to the cue length
without drift. Packet timing uses pkt_timebase rather than assuming a
1/1000 time base. Out-of-range, non-monotonic and malformed timestamps
are ignored; cues without timestamps are emitted unchanged.
ASS {\kf} only approximates WebVTT timed text (no ::cue(:past/:future)).
Fixes: ticket #23289
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Same approach as median_sad16, processing one 8 pixel row per XMM
register.
median_sad_1_c: 141.4 ( 1.00x)
median_sad_1_ssse3: 29.1 ( 4.86x)
Benchmarks and tests run with checkasm on an Intel Core Ultra 7 155H.
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
The median_sad functions have NEON implementations but no x86 ones,
so x86 always used the C code. x86_64 only due to register pressure.
median_sad_0_c: 314.5 ( 1.00x)
median_sad_0_ssse3: 51.1 ( 6.16x)
Benchmarks and tests run with checkasm on an Intel Core Ultra 7 155H.
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
The generic code was setting the last packet duration based on the input frame
while ignoring the fact the encoder may have output an initial padding amount
of samples in the first (e.g. 481 for mp2, 256 for AC3, etc).
Signed-off-by: James Almer <jamrial@gmail.com>
Both the seek index and the stream duration are constantly being updated as
trun boxes are read.
Fixes mpv issue 18149.
Signed-off-by: James Almer <jamrial@gmail.com>
The first computation in a linear row doesn't have anything to
accumulate to, so a multiply-accumulate instruction won't be used
either way. This led to identical functions being instantiated for
different params.
There is no easy optimization that can be triggered by knowing that the
offset is exactly 1. This led to identical functions being instantiated
for different params.
b488ee55 relaxed the check and stopped taking the number of components
into account. This led to the generation of duplicate read/write
functions for single component packed/planar.
ops_entries.c wasn't regenerated to take this into account; instead
some conversions were no longer being supported for the neon backend.
The functions do the same, yet the dedicated functions
from hpeldsp are more optimized.
(Notice that the motion estimation code only uses
aligned scratchpad buffers as destination when using
hdsp functions, so Snow-specific functions with relaxed
alignment like for the me-cmp API are not necessary.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: NULL pointer dereference
As a sideeffect this also sets the timescale correctly if an
intermediate matches MOV_TIMESCALE_Q, the previous code stoped
in that case as it could not distinguish it from the overflow detection
Regression since: 51f5f60443
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Register check_commit_msg.sh as a commit-msg stage hook in the
pre-commit configuration so developers get immediate feedback
on commit message format during `git commit`.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Add a shell script that validates commit messages against FFmpeg
conventions. Based on the lint_commit_msg.py checker from mpv
(Kacper Michajłow, Timo Rothenpieler).
Supports three entry points: stdin (for CI pipelines), file
argument (for pre-commit commit-msg hook), and revision range
(for manual batch checking).
Checks enforced (errors block):
- Subject matches "component[/module]: description" pattern
- No conventional-commits style (feat:/fix:/chore:/refactor:)
- Blank line between subject and body
- No duplicate Signed-off-by from same person
- No multiple subject-like lines in body (squash-mess detection)
Checks that only warn:
- Subject line > 120 characters
- Trailing whitespace on subject line
- Subject should not end with a period
- Prefix should not contain file extension (.c, .h, etc.)
Merge, Revert and Reapply subjects are exempted from format checks.
Usage:
echo "avcodec/vvc: fix pred" | sh tools/check_commit_msg.sh
sh tools/check_commit_msg.sh .git/COMMIT_EDITMSG
sh tools/check_commit_msg.sh HEAD~5..HEAD
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Possible if src of the PRED4x4_LOWPASS macro is not used lateron.
Saves 195B of .text here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Frequency-domain mono/stereo decoding at several sampling rates, M/S,
TNS, and target_level-based loudness normalization, compared against
the reference decoder output of the ISO/IEC 23003-3 conformance
sequences (at -16, -24 and -31 dB targets driven by loudnessInfoV1
metadata), plus an exhale-encoded stream carrying v0 loudnessInfo().
Real-world xHE-AAC streams and the ISO/IEC 23003-3 conformance
sequences carry their loudness metadata exclusively as loudnessInfoV1()
inside loudnessInfoSetExtension(), which was previously rejected with
AVERROR_PATCHWELCOME, making such streams undecodable and loudness
normalization inoperative on them.
loudnessInfoV1() is identical to loudnessInfo() apart from an added
eqSetId field. Parse it, restrict measurement selection to
eqSetId == 0 (in line with the downmixId/drcSetId restrictions), and
skip unknown loudnessInfoSetExtension() payloads using their explicitly
coded size instead of erroring out.
interleaved_yuv_to_planar, shared by uyvytoyuv422, uyvytoyuv420,
yuyvtoyuv422 and yuyvtoyuv420, only handled even widths. The packed
UYVY/YUYV macroblocks are pixel pairs and the trailing half macroblock of
an odd width was mishandled:
- the slow path (width <= 31) decrements its pixel counter by two from an
odd value, so it never reaches zero and the loop runs far past the line,
overwriting the destination (observed as a crash in checkasm);
- the fast path (width >= 32) shifts the tail pointers back by width-32 and
reprocesses an overlapping, misaligned tuple, producing wrong samples and
dropping the last chroma column.
Process only whole pixel pairs and emit the trailing odd column from a
per-line epilogue that matches the C reference: for yuv422 one Y, U and V
sample; for yuv420 the Y of both lines of the pair with the chroma averaged
across them, and luma only for the final line when the height is odd. The
empty even part (width 0 or 1) is guarded so the slow path no longer enters
its run-past loop.
All four variants are now bit-exact with the C reference for even and odd
widths. Verified with checkasm under qemu-aarch64.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
uyvytoyuv422 converts packed UYVY, whose macroblocks are pixel pairs, and
the SIMD code only handled even widths. On an odd width the trailing half
macroblock made the kernel write past the end of the Y/U/V destinations:
the AVX512ICL masked tail dropped the odd pixel and the fall-through
re-entered the SIMD loop, writing a full mmsize*2 chunk past the planes
(127 bytes of Y, 63 of U and 63 of V); the sse2/avx/avx2 scalar tail
wrote one byte past the Y plane.
Process only whole pairs and emit the trailing odd column from a small
per-row epilogue that matches uyvytoyuv422_c (ydst[w-1] = src[2w-1],
udst[cw-1] = src[2w-2], vdst[cw-1] = src[2w]).
All four SIMD variants are now bit-exact with the C reference for even and
odd widths and no longer overwrite the destination. Verified on AVX512ICL
hardware (Ryzen 9 9950X) with checkasm.
Found-by: Claude (Anthropic). Human-verified and reported by Omkhar Arasaratnam <omkhar@linkedin.com>.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When extending the edges of the reconstructed reference frame, the chroma
plane width and height were passed to draw_edges() as w >> chroma_h_shift
(floor) instead of AV_CEIL_RSHIFT(). For an odd width with subsampled chroma
(e.g. 4:2:0) the chroma plane is one column wider than the floor, and
draw_edges() replicates the edge columns, so it overwrote the last real
chroma column with the previous one. The decoder does not draw_edges() its
reference, so its copy kept the correct value: the encoder and decoder
references diverged and every following inter frame was reconstructed
differently by the two, breaking bit-exact (lossless) round-tripping and
drifting lossy inter coding, for any odd-width 4:2:0 snow stream.
Use AV_CEIL_RSHIFT(), matching the input_picture edge extension just above.
Found-by: Claude
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
get_dc() divides the accumulated, OBMC-weighted DC by aa, the sum of the
squared OBMC weights taken over the in-plane pixels. When an OBMC block
falls entirely outside the plane - e.g. a tiny chroma plane after mcdeint
splits a frame into fields - no pixel contributes, aa stays 0 and the
ROUNDED_DIV() divides by zero (SIGFPE). ab is 0 in exactly the same case,
so the result degenerates to 0; return it directly.
Reproducible with the GPL mcdeint filter in slow/extra_slow mode, e.g.
ffmpeg -f lavfi -i testsrc=s=128x2 -vf mcdeint=mode=slow -f null -
Add a self-contained lavfi-based FATE regression test for the slow mode,
which previously crashed and is therefore not covered by the existing
sample-based fast/medium tests.
Fixes trac ticket #7779.
Signed-off-by: Bogdan Lisman <bogdan@pydevsolutions.com>
pts_correction_num_faulty_pts and pts_correction_num_faulty_dts were not
cleared by ff_decode_flush_buffers(), so they survived avcodec_flush_buffers().
After a seek, guess_correct_pts() therefore kept biasing its reordered-pts vs
dts choice on pre-seek history instead of starting fresh as it does after
ff_decode_preinit(), which already zeroes both counters. This could yield an
incorrect AVFrame.best_effort_timestamp on the frames following a seek.
Reset both counters on flush, next to the existing last_pts/last_dts reset, so
the decoder's timestamp-correction state is fully reinitialized.
Fixes: ticket #11645
Reported-by: keks51
Signed-off-by: Bogdan Lisman <bogdan@pydevsolutions.com>
Ramiro Polla
Andreas Rheinhardt
Azat Nurgaliev
Araz Iusubov
Jun Zhao
marcos ashton
James Almer
Dawid Kozinski
Michael Niedermayer
Romain Beauxis
Steve Lhomme
Dmitrii Gershenkop
Zhao Zhili
Lynne
Hunter Kvalevog
Bogdan Lisman
Marvin Scholz