The end of 8-bit/pixel_code_string() is signalled with two zero bytes, so we
should read those from the buffer instead of one. We keep supporting though our
own buggy encoder which only put one zero byte there.
Signed-off-by: Marton Balint <cus@passwd.hu>
Initially, avcodec/srtenc.c was outputting CRLF [1]. Later, a real SRT
muxer was added [2], which outputs LF. The original srtenc.c was
converted to use the muxer [3], changing its output to LF, except for
newline characters within subtitle text.
Fix this to avoid producing SRT files with mixed line endings.
[1] 8e43b6fed9
[2] 9e63c30daa
[3] 55180b3299
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This will ensure it will be stored in the stream's private context, so it can
be fetched and replaced as required.
Fixes a regression since eefa6de7d5.
Fixes avc-intra-panasonic-AG-HPX301E.mov
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: writing 1 byte over the end of the array
Fixes: BIGSLEEP-433502298/test.xml
Found-by: Google Big Sleep
A prettier solution is welcome!
A testcase exists only for the baseurl case
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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
