choose_pix_fmts() used the dynamic buffer API to write strings;
as is common among uses of this API, only opening the dynamic buffer
was checked, but not the end result, leading to crashes in case
of allocation failure.
Furthermore, some static strings were duplicated; the allocations
performed here were not properly checked: Allocation failure would
be treated as "could not determine pixel format".
The first issue is fixed by switching to the AVBPrint API which allows
to easily perform checks at the end. Furthermore, the internal buffer
avoids almost all allocations in case the AVBPrint is used.
The AVBPrint also allows to solve the second issue in an elegant way,
because it allows to return the static strings directly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not really natural, it requires internal allocations
of its own and its error handling is horrible (i.e. the implicit
(re)allocations here are unchecked).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, the h264_redundant_pps_bsf stored the initial value
of pic_init_qp_minus26 of the most recently encountered PPS;
it also modified the slices based upon to assumption that
the most recent PPS is the PPS the slice belongs to.
Yet this assumption is flawed, as there can be several PPS
with different IDs that are visible at any given time.
If these have different pic_init_qp_minus26 values,
the output can be invalid.
Fix this by directly using the pic_init_qp_minus26 value of
the input PPS.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
extradata_pic_init_qp is unset since
fa75e43875
(and resetting current_pic_init_qp to the value it had in extradata
never made much sense).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not documented that freeing the last (and only) entry of
an AVDictionary frees the dictionary.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SWR_CH_MAX is internal only and the arrays are therefore not required
to have that many elements (and they typically don't do it). So remove
this potentially confusing hint.
(Newer versions of GCC emit -Warray-parameter= warnings for this,
because the definition with explicit size differs from the declaration
(which leaves the size unspecified); this is IMO a false-positive,
because definition and declaration didn't conflict, but anyway it is
fixed by this commit.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The number of audio channels is stored after the magic number
identifying the audio format. Prior to this patch the code has been
reading it earlier, causing files with only one audio channel to be
handled incorrectly.
Reviewed-by: Peter Ross <pross@xvid.org>
Fixes FATE failures if e.g. libavdevice is disabled.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The mpeg4 encoder is slice-threaded and its output depends upon
the number of threads used. Therefore all tests of this encoder
use a hardcoded number of threads (ENC_OPTS in fate-run.sh contains
"-threads 1"; only the vsynth%-mpeg4-thread tests override this
for the mpeg4 encoder, but they also use a hardcoded value to
be consistent across different systems); only the new shortest
and copy-shortest[12] (implicitly due to the sample used) tests
don't and this leads to FATE-failures.
Fix this by explicitly setting the thread count.
Also switch the shortest test to framecrc, because hashing side data
is itchy even though the side data used here (AV_PKT_DATA_QUALITY_STATS)
has a defined endianness.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This filter flips the input video both horizontally and vertically
in one compute pipeline, and it's no need to use two pipelines for
hflip_vulkan,vflip_vulkan anymore.
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
The format of a mov_text (3GPP Timed Text) sample is:
uint16_t text_length;
uint8_t text[text_length];
TextSampleModifierBox text_modifier;
Yet in case our encoder receives an AVSubtitle with multiple
ASS AVSubtitleRects, it creates something like this:
uint16_t text_length;
uint8_t text[text_length_1];
TextSampleModifierBox text_modifier_1;
uint8_t text[text_length_2];
TextSampleModifierBox text_modifier_2;
...
where text_length is the sum of all the text_length_*.
This commit fixes this by writing the TextSampleModifierBoxes only
after all the rects have been written.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids abusing a variable called length for the return value
and ensures that the AVBPrint is always reset before using it;
previously this has been forgotten in some error paths.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Regression since af043b839c.
Fixes ticket #9409.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Don't mark all streams as finished, instead make sync_opts keep track of the
stream's duration, and set recording_time to it, same as in transcoding paths.
Fixes tickets #9512 and #9513.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: out of array read
Fixes: 40284/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP3_fuzzer-4599568176644096
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Timeout
Fixes: 41083/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_GEM_fuzzer-5843826518917120
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Adds demuxer for Square Enux SCD files.
Based off [1] and personal investigation.
This has only been tested against Drakengard 3 (PS3) *_SCD.XXX files
(big-endian). As it is highly likely that FFXIV (PC) files are little-endian,
this demuxer is marked as experimental until this can be confirmed.
[1]: http://ffxivexplorer.fragmenterworks.com/research/scd%20files.txt
Reviewed-by: Peter Ross <pross@xvid.org>
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Fixes ticket #9537.
Probably a regression since 2b3206891649f317c20993411efef4bee39ae784.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Currently they are ordered as-written (i.e. by increasing position);
in case av_interleaved_write_frame() is used, this is (mostly)
the same as ordered by increasing dts.
Yet the Matroska specification strongly recommends (SHOULD) that
the CuePoints be sorted by CueTime. mkvalidator warns when they are
not. Therefore this commit sorts them accordingly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Freeing the new H.264 specific fields has been forgotten.
(This leak only appears in case the encoder has not been completely
drained.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, it has only been freed when the QSVFrame is reused,
so that the last one contained in it leaked at the end.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since commit 3bbe0c210b05fc6fbd7b1d4bbd8479db7f2cf957, the Payloads
array of every QSVFrame leaks as soon as the frame is reused;
the leak is small and not very noticeable, but if there is an attempt
to use said array the ensuing crash is much more noticeable.
This happens when encoding H.264 with A53 CC side data.
Furthermore, if said array can not be allocated at all, an AVFrame
leaks.
Fix all of this by not allocating the array separately at all; put it
in QSVFrame instead and restore the Payloads array upon reusing the
frame.
Finally, use av_freep() instead of av_free() to free the payload
entries.
Reviewed-by: Xiang, Haihao <haihao.xiang@intel.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If fifo_thread_recover() succeeds immediately after
fifo_thread_dispatch_message() fails, the dts of the packet is scaled
twice, causing cur_dts to be abnormally large and "Application provided
invalid, non monotonically increasing dts to muxer in stream" to occur
repeatedly.
Steps to reproduce:
1. ffmpeg -f lavfi -i testsrc -c:v libx264 -map 0:v -flags +global_header -f fifo -fifo_format flv -attempt_recovery 1 -recover_any_error 1 rtmp://example.com/livekey
2. set a breakpoint on fifo_thread_recover
3. force disconnect from the rtmp server
4. wait for break
5. reconnect to the rtmp server
6. resume execution of ffmpeg
Signed-off-by: Ryoji Gyoda <gy.cft4@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
FLV AMF tags have a 24bit field for timestamps plus an 8bit for extended
timestamps.
All FLV AMF tags except when we write metadata handle this correctly
using the put_timestamp function.
Until now when writing metadata we were only using the first
24 bits and thus the timestamp value was wraping around 4 hours 40
minutes (16,800,000 ms, max 24 bit value 16,777,216) of playback.
This commit fixes this applying this same function put_timestamp
for the metadata FLV tag.
Signed-off-by: Marton Balint <cus@passwd.hu>
This debug code can be quite slow on constructed streams
Fixes: Timeout
Fixes: 38907/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-6334628852531200
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -776522110086937600 * 16 cannot be represented in type 'long'
Fixes: 40563/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6644829447127040
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Fixes: Timeout
Fixes: 40481/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VQA_fuzzer-6502647583080448
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
