Ticket11686 hinted at one of these overflows
this fixes them all
Issue in line 1325/1326 found by HAORAN FANG <xfanghaoran@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Consider the following sequence of NALUs (with some PPSs etc. omitted
for brevity):
1. SPS (ID=0, content=A)
2. IDR (SPS=0)
3. IDR (SPS=0)
4. SPS (ID=0, content=B)
5. TRAIL (SPS=0)
When decode_sps is called for NALU 3., ps->sps_id_used is cleared as
IDRs are one way of forming a CLVSS. Then, old_sps is non-NULL
containing the result of calling decode_sps for NALU 2. We haven't
received any SPSs between NALUs 2. and 3., therefore old_sps and rsps
are identical and the function returns. The issue is that, at this
point, ps->sps_id_used is still zero despite the SPS being used for IDR
3. This results in the check for conflicting SPSs not working properly
when decode_sps is called for NALU 5., allowing prediction between
pictures with different SPSs and probably all sorts of other
shenanigans.
Patch addresses the problem outlined above by also setting
ps->sps_id_used in the early return case.
This was introduced in commit 9c43703, to support a codec "extension"
in the prores_aw encoder.
This removes the chroma fill loop, and instead performs the inverse
transform on null coefficients, which achieves the same result and
fixes an off-by-one in the chroma values produced.
Updated test to reflect this change.
Fixes issue #20018.
Note that Codec Descriptors are not written for all these ai** codec tags, and no
considerations were ever made to ensure parameter sets are present in muxed packets.
Their usage may result in unplayable files if parameter sets are only available
in extradata (Default behavior for x264 encoding when combined with this muxer).
Signed-off-by: James Almer <jamrial@gmail.com>
Adds D3D11 input surface support to the MediaFoundation encoder (mfenc),
allowing direct encoding of GPU frames without readback to system memory.
This improves performance and compatibility when used alongside scale_d3d11.
Signed-off-by: Dash Santosh <dash.sathyanarayanan@multicorewareinc.com>
This commit introduces a new hardware-accelerated video filter, scale_d3d11,
which performs scaling and format conversion using Direct3D 11. The filter enables
efficient GPU-based scaling and pixel format conversion (p010 to nv12), reducing
CPU overhead and latency in video pipelines.
There is no convenient way, from the command line, to figure out which
formats a filter actually supports. This commit changes that by adding a
log output, at debug level, to simply print the list of formats each filter
advertises on its links, before any negotiation.
Furthermore, we can use the exact same helper function to also print out the
corresponding filter links when there is an error during format negotiation.
We need to use AV_BRINT_SIZE_UNLIMITED because the default format list for
filters like vf_scale is about 1700 characters long, significantly larger than
the the 1 kB default buffer.
This function overreads the input plane for odd dimensions, because the
chroma plane is always rounded up, which means (xy << subsample) + 1 exceeds
the actual alpha plane size.
To verify:
valgrind ffmpeg -pix_fmt yuva420p -f lavfi -i color -vf \
"scale=1x1,format=yuva420p,scale=alphablend=uniform_color,format=yuv420p \
-vframes 1 -f null -
Fixes: https://trac.ffmpeg.org/ticket/11692
That occurs when H261, H263, and MPEG4 decoders are disabled.
Signed-off-by: zhaozhenghang <15083277223@163.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
If a packet contains new extradata within a side data entry, save for
specific cases it means the coded stream changed. If ignored, upon
demuxing every packet from then onwards may be undecodable.
Signed-off-by: James Almer <jamrial@gmail.com>
The first sample in the stsc box may not refer to the first stsd entry.
This is the case in h264/thezerotheorem-cut.mp4, and as such the
fate-h264_redundant_pps-side_data test is updated accordingly.
Signed-off-by: James Almer <jamrial@gmail.com>
BIO_get_new_index() is static counter meant to get index for custom bio
type definition. As we can read in the documentation:
> Note that BIO_get_new_index() can only be used 127 times before it
> returns an error.
We cannot call it repeatedly, because it will fail eventually.
To my understanding the index is not needed in our use and we could
safely use BIO_TYPE_NONE. Documentation states:
> type can be set to either BIO_TYPE_NONE or via BIO_get_new_index() if
> a unique type is required for searching (See BIO_find_type(3))
We don't use any search related functions.
This reverts commit 816dad231f.
Fixes: https://github.com/mpv-player/mpv/issues/16589
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Fixes: writing over the end of the array
Fixes: BIGSLEEP-434637586/payload
Regression since: b22ce90d42
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This change improves pipeline stability and reduces
dynamic GPU surface allocations when using AMF with copy_frame = 1.
This optimization has no negative effect.
The new logic should be easier to follow.
It also uses ff_inlink_consume_frame() for all simple passthrough operations
making custom get_audio_buffer callback unnecessary.
Fate changes are because the new logic does not repacketize input audio up
until the crossfade. Content is the same.
Signed-off-by: Marton Balint <cus@passwd.hu>
Prior to this patch, kth_order_egk_decode could read arbitrarily
large values which then overflowed and caused various issues.
Patch fixes this by making kth_order_egk_decode falliable,
requiring the caller to specify an upper bound and returning an
error if the read value would exceed that bound.
This patch resolves the same issue as
eb52251c0a, but I think this is the proper
fix as it also addresses issues with syntax elements besides
ff_vvc_num_signalled_palette_entries.
Signed-off-by: Frank Plowman <post@frankplowman.com>
The end_ prefix is confusing and may have contributed the mixup
fixed in the previous commit
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: reading the duration from before the start of the allocated buffer.
Regression since: 36ec9217e6
Fixes: BIGSLEEP-433513232/test
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also ensure that the dst buffers are not too big
(they had the right size for >8 bit depths and were therefore
too big for eight bit, letting potential buffer overflows
in the eight bit version go undetected).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
