Previously one could only replace the entire array with a new one
deserialized from a string. The new API allows inserting, replacing, and
removing arbitrary element ranges.
The code previously returned ENOMEM, despite this not being an
allocation problem, but rather a bitstream problem referring to data not
currently available.
Fixes playback of such streams, as it allows further processing of NAL
units after skipping the broken SEI NAL.
Implemented gpu driver check.
10-bit patch works incorrectly on driver version lower than 23.30.
Signed-off-by: Dmitrii Ovchinnikov <ovchinnikov.dmitrii@gmail.com>
Fix "ost->st->avg_frame_rate = ost->frame_rate" in streamcopy_init()
being reset to input's frame rate a few lines below.
Note that in current code, there are some discrepancies amongst the
muxers. For example, avienc relies on time_base, so it is not affected
by this patch, whereas mxfenc and matroskaenc do use avg_frame_rate,
so this patch fixes -r being honored.
In the updated fate test, the input is (wrongly) probed as 50fps. With
this patch, the correct value (25fps) is successfully forced with -r.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The time_base was a bad guess.
Currently, fate-time_base test data assumed that overriding the input
time_base would affect the frame_rate, but this behaviour is not
documented, so just fix the fate data now that this is fixed.
Fix regression since 10185e2d4c:
previously, when streamcopying, the time_base was guessed from the
frame_rate considering it is often constant, so guessing the frame_rate
back from the time_base was often not a problem.
To reproduce:
ffmpeg -i fate-suite/mpeg2/dvd_still_frame.vob -an -c copy out.mxf
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The x86 optimized dct_quantize only calculates the last nonzero
coefficient correctly if the zigzag scan order is used. For the
alternate scan order, this value is incorrect.
To work around this, the dct_unquantize functions process the entire
block if the alternate scan order is used.
But a second workaround (bb198e198a) was added that recalculates the
last nonzero coefficient after dct_quantize is called if the alternate
scan order is used.
This commit removes the first workaround, which became redundant.
It's safe to assume that LOCAL_ALIGNED_16 does indeed align. Otherwise
we would have many more problems...
This assert was added in f8188626 all the way back in 2003.
Fixes:
https://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-tsan&time=20240823175808
Reproduction steps:
./configure --enable-memory-poisoning --toolchain=gcc-tsan --disable-stripping && make fate-vvc
Root cause:
We hold the current frame's lock while updating progress for other frames,
which also requires acquiring other frame locks. This could potentially lead to a deadlock.
However, I don't think this will happen in practice because progress updates are one-way, with no cyclic dependencies.
But we need this patch to make FATE happy.
Implement load/save loop filter and segment parameters defined in
section 7.20 and 7.21 in spec for show_existing_frame frames.
Fixes ticket #11151.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
If the demuxer does not provide per-stream indexes, the generic seek search can
attempt to read the whole media file from the beginning when seeking. For large
MXF files this can cause huge lockups for a seek after the last timestamp,
which will eventually fail. So let's disable the generic seek for mxf, the
demuxer's own seek code should handle seeking just fine.
Signed-off-by: Marton Balint <cus@passwd.hu>
Recently, I have been experiencing an increasing number of user that use ffmpeg
to retrive RTSP stream from personal mediaproxies (e.g. MediaMtx) with
authorization based on JWT. The current length of PATH does not permit to
insert the token in the URL failing the authorization with no possibilities to
get the video.
VLC has just modified the RSTP max URL length, and it permits to use token
inside the URL.
For these reasons, I propose this patch to extend the PATH buffer from 1024 to
2048 in order to use tokens and the authorization process based on JWT.
Signed-off-by: Marton Balint <cus@passwd.hu>
