The av_sscanf() will filter lines like "Scenarist_SCC V1.0" out.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, the scc demuxer not only read the line that it intends
to process, but also the next line, in order to be able to calculate
the duration of the current line. This approach leads to unnecessary
complexity and also to bugs: For the last line, the timing of the
next subtitle is not only logically indeterminate, but also
uninitialized and the same applies to the duration of the last packet
derived from it.* Worse yet, in case of e.g. an empty file, it is not
only the duration that is uninitialized, but the whole timing as well
as the line buffer itself.** The latter is used in av_strtok(), which
could lead to crashes. Furthermore, the current code always outputs
at least one packet, even for empty files.
This commit fixes all of this: It stops using two lines at a time;
instead only the current line is dealt with and in case there is
a packet after that, the duration of the last packet is fixed up
after having already parsed it; consequently the duration of the
last packet is left in its default state (meaning "unknown/up until
the next subtitle"). If no further line could be read, processing
is stopped; in particular, no packet is output for an empty file.
*: Due to stack reuse it seems to be zero quite often; for the same
reason Valgrind does not report any errors for a normal input file.
**: While ff_subtitles_read_line() claims to always zero-terminate
the buffer like snprintf(), it doesn't do so if it didn't read anything.
And even if it did, it would not necessarily help here: The current
code jumps over 12 bytes that it deems to have read even when it
hasn't.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Before adts_aac_resync would always bail out after probesize amount
of bytes had been progressed from the start of the input.
Now just query the current position when entering resync, and at most
advance probesize amount of data from that start position.
Fixes#9433
There can only be a maximum of 255 entries in a tfrf tag, so using
more makes no sense; moreover, several size computations can overflow
in this case. Fix this by limiting it to 255.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this by using the AVStream's priv_data for the buffer holding
the packet size data.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If an array for the packet sizes could not be successfully reallocated
when writing a packet, the CAF muxer frees said array, but does not
reset the number of valid bytes. As a result, when the trailer is
written later, avio_write tries to read that many bytes from NULL,
which segfaults.
Fix this by not freeing the array in case of error; also, postpone
writing the packet data after having successfully (re)allocated the
array, so that even on allocation error the file can be correctly
finalized.
Also remove an unnecessary resetting of the number of size entries
used at the end.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(As long as avio_write() only accepts an int, it makes no sense
to try to support sizes that don't fit into an int.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: signed integer overflow: 9223372036854775360 + 536870912 cannot be represented in type 'long'
Fixes: 37940/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6095637855207424
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This avoids a -Wstringop-truncation warning from GCC which takes
issue with the fact that the destination might not be NUL-terminated.
Reviewed-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The terminating '\0' is no longer included in the size of
the extradata output by the demuxer since commit
36e61e24e7.
E.g. if one remuxes the JACOsub sample JACOsub_capability_tester.jss
from the FATE suite, one receives a file not recognized as JACOsub
before this patch.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: memleak
Fixes: 38893/clusterfuzz-testcase-minimized-ffmpeg_dem_CONCAT_fuzzer-4785231933079552
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: assertion failure
Fixes: 38332/clusterfuzz-testcase-minimized-ffmpeg_dem_DHAV_fuzzer-4522405595316224
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
SRTSOCKET is an abstraction designed by libsrt, it's not guaranteed
to be a real file descriptor. Even if it is, it should not be
operated directly outside of libsrt.
Signed-off-by: Marton Balint <cus@passwd.hu>
It's useful for test client which pass streamid to ffmpeg/ffplay.
For example, use ffmpeg to test streamid support in VLC:
./ffmpeg -v info -re -i foo.mp4 -c copy -f mpegts -mode listener srt://127.0.0.1:9000
./vlc srt://127.0.0.1:9000?streamid=foobar
Signed-off-by: Marton Balint <cus@passwd.hu>
When a possible overflow was detected, there was a break to exit the while
loop. However, it should have already substracted 2 bytes from
program_info_length (descriptor ID + length).
Fixes ticket #9422.
Signed-off-by: Marton Balint <cus@passwd.hu>
libavformat/utils.c has over 4800 lines and is supposed to contain
"various utility functions for use within FFmpeg". In reality it
contains all that and the whole demuxing core of libavformat.
This is especially bad, because said file includes the FFMPEG_VERSION
(the git commit sha) so that it is rebuilt whenever the commit HEAD
points to changes. Therefore this commit makes it smaller by moving
the demuxing code out to a new file, demux.c (in analogy to mux.c
for the muxing code).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
libavformat/utils.c has over 5500 lines and is supposed to contain
"various utility functions for use within FFmpeg". In reality it
contains all that and the whole demuxing+seeking core of libavformat.
This is especially bad, because said file includes the FFMPEG_VERSION
(the git commit sha) so that it is rebuilt whenever the commit HEAD
points to changes. Therefore this commit starts making it smaller
by factoring the seeking code out.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this by allocating AVStream together with the data that is
currently in AVStreamInternal; or rather: Put AVStream at the
beginning of a new structure called FFStream (which encompasses
more than just the internal fields and is a proper context in its own
right, hence the name) and remove AVStreamInternal altogether.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This gets rid of ugly "->internal" and is in preparation for removing
AVStreamInternal altogether.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this by allocating AVFormatContext together with the data that is
currently in AVFormatInternal; or rather: Put AVFormatContext at the
beginning of a new structure called FFFormatContext (which encompasses
more than just the internal fields and is a proper context in its own
right, hence the name) and remove AVFormatInternal altogether.
The biggest simplifications occured in avformat_alloc_context(), where
one can now simply call avformat_free_context() in case of errors.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This gets rid of ugly "->internal" and is in preparation for removing
AVFormatInternal altogether.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: signed integer overflow: -682581959642593728 * 16 cannot be represented in type 'long'
Fixes: 37883/clusterfuzz-testcase-minimized-ffmpeg_dem_MV_fuzzer-5311691517198336
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: signed integer overflow: 4611686025627387904 + 4611686025627387904 cannot be represented in type 'long'
Fixes: 35489/clusterfuzz-testcase-minimized-ffmpeg_dem_SBG_fuzzer-4862678601433088
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: signed integer overflow: 65312 * 65535 cannot be represented in type 'int'
Fixes: 32832/clusterfuzz-testcase-minimized-ffmpeg_dem_RM_fuzzer-4817710040088576
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: 2788626175500000000 + 7118941284000000000 cannot be represented in type 'long'
Fixes: 35215/clusterfuzz-testcase-minimized-ffmpeg_dem_SBG_fuzzer-6123272247836672
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: -5994697211974418462 + -3255307777713450286 cannot be represented in type 'long'
Fixes: 35332/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-5868035117285376
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
Fixes: 34651/clusterfuzz-testcase-minimized-ffmpeg_dem_JACOSUB_fuzzer-5157941012463616
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: 37030/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5387719147651072
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Up until now, ff_write_chained() copied the packet (manually, not with
av_packet_move_ref()) from a packet given to it to a stack packet whose
timing and stream_index is then modified before being sent to another
muxer via av_(interleaved_)write_frame(). Afterwards it is intended to
sync the fields of the packet relevant to freeing again; yet this only
encompasses buf, side_data and side_data_elems and not the newly added
opaque_ref. The other fields are not synced so that the returned packet
can have a size > 0 and data != NULL despite its buf being NULL (this
always happens in the interleaved codepath; before commit
fe251f77c8 it could also happen in the
noninterleaved one). This leads to double-frees if the interleaved
codepath is used and opaque_ref is set.
This commit therefore changes this by directly reusing the packet
instead of a spare packet. Given that av_write_frame() does not
change the packet given to it, one only needs to restore the timing
information to return it as it was; for the interleaved codepath
it is not possible to do likewise*, because av_interleaved_write_frame()
takes ownership of the packets given to it and returns blank packets.
But precisely because of this users of the interleaved codepath
have no legitimate expectation that their packet will be returned
unchanged. In line with av_interleaved_write_frame() ff_write_chained()
therefore returns blank packets when using the interleaved codepath.
Making the only user of said codepath compatible with this was trivial.
*: Unless one wanted to create a full new reference.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is unnecessary and also ill-defined: av_malloc() returns a 1-byte
block of memory in this case, but this is not documented.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The chapters are independently allocated, so that comparing
the pointers is undefined behaviour. Furthermore, its result
is not platform-independent (and may not even be deterministic
on a particular platform). So compare the chapters' ids instead.
(avpriv_new_chapter() ensures that there are no duplicate ids.)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This structure is only used for demuxers (mostly in
avformat_find_stream_info()), so only allocate it for them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It has been allocated and initialized in avformat_find_stream_info()
until fd0368e7ca when the structure
was moved to AVStreamInternal and its allocation to avformat_new_stream.
In order to also initialize the struct for new streams that only get
created during avformat_find_stream_info() said the initialization has
been added to avformat_new_stream() later. Due to the Libav-FFmpeg split
this has been done twice: In 4cda8aa1c5
and in 30c26c2442. The initialization in
avformat_find_stream_info() has not been removed at all despite being
redundant. This commit removes it and the duplicated initialization in
avformat_new_stream().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The packet queue is already flushed in avformat_free_context() which
is called a few lines below.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
An AVStream's internal AVCodecContext is pretty much unused for muxing:
The only place where any of its fields are set is
avformat_transfer_internal_stream_timing_info() where its time base is
set based upon the desired output format. The max_b_frames field is
never set at all, so don't read it in mux.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since 1c0885334d ff_compute_frame_duration
is only called from within utils.c and only for demuxers. So make it
static and remove the code in it that deals with muxers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AVFormatContext.internal is already allocated by
avformat_alloc_context() on success; and on error,
avformat_alloc_context() cleans up manually without
avformat_free_context().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The WebM DASH Manifest demuxer creates a comma-delimited list of
all the timestamps of index entries. It allocates 20 bytes per
timestamp; yet the largest 64bit numbers have 20 decimal digits
(for int64_t it can be '-'+ 19 digits), so that one needs 21B
per entry because of the comma (resp. the final NUL).
The code uses snprintf, but snprintf returns the strlen of the string
that would have been written had the supplied buffer been big enough.
And if this is 21, then the next entry is written at an offset of 21
from the current position. So if enough such entries exist, the buffer
won't suffice.
This commit fixes this by replacing the allocation of buffer for
the supposedly worst-case with dynamic allocations by using an AVBPrint.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: signed integer overflow: 9223372034248226491 + 3275247799 cannot be represented in type 'long'
Fixes: clusterfuzz-testcase-minimized-audio_decoder_fuzzer-4538729166077952
Reported-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 1179337772 + 1392508928 cannot be represented in type 'int'
Fixes: 34088/clusterfuzz-testcase-minimized-ffmpeg_dem_AVI_fuzzer-5846945303232512
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Don't allocate the buffer for the title ourselves, leave it to
av_dict_set(). This simplifies freeing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
A single VorbisComment consists of a length field and a
non-NUL-terminated string of the form "key=value". Up until now,
when parsing such a VorbisComment, zero-terminated duplicates of
key and value would be created. This is wasteful if these duplicates
are freed shortly afterwards, as happens in particular in case of
attached pictures: In this case value is base64 encoded and only
needed to decode the actual data.
Therefore this commit changes this: The buffer is temporarily modified
so that both key and value are zero-terminated. Then the data is used
in-place and restored to its original state afterwards.
This requires that the buffer has at least one byte of padding. All
buffers currently have AV_INPUT_BUFFER_PADDING_SIZE bytes padding,
so this is ok.
Finally, this also fixes weird behaviour from ogm_chapter():
It sometimes freed given to it, leaving the caller with dangling
pointers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This can be achieved by allocating the AVIOContext and
the dynamic buffer's opaque and internal write buffer together.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Currently AVIOContext's private fields are all over AVIOContext.
This commit moves them into a new structure in avio_internal.h instead.
Said structure contains the public AVIOContext as its first element
in order to avoid having to allocate a separate AVIOContextInternal
which is costly for those use cases where one just wants to access
an already existing buffer via the AVIOContext-API.
For these cases ffio_init_context() can't fail and always returned zero,
which was typically not checked. Therefore it has been made to not
return anything.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is the more natural place for it given that it only deals with I/O;
in fact, the function already has the ffio prefix and its declaration
already is in avio_internal.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Includes basic support for both the ISMV ('dfxp') and MP4 ('stpp')
methods. This initial version also foregoes fragmentation support
in case the built-in sample squashing is to be utilized, as this
eases the initial review.
Additionally, add basic tests for both muxing modes in MP4.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
Up until now, the Matroska muxer did not use the dispositions it is
given as-is; instead it by default overrode the disposition of the first
track of a kind (audio, video, subtitles) if no track of this kind has
the default disposition set. And up until recently, it also enforced
by default that no more than one track of each kind be marked as
default.
The rationale for the former is that there are lots of containers which
lack the concept of default streams, so that it is not uncommon for no
stream to be marked as default at all; the rationale for the latter was
that up until recently, it was dubious whether the Matroska specification
allowed more than one default stream for track type (e.g. mkvmerge
disallowed it). It was this point which led to the implementation of
the above mentioned behaviour inspired by mkvmerge.
Yet the Matroska specifications have changed and now explicitly allow
to set more than one track of each type as default, so that the main
reason of not using the dispositions as-is was rendered moot. Therefore
this commit changes the default to pass the disposition through.
The matroska-mpegts-remux FATE-test has been updated to still use the
old "infer" mode so that it is still covered by FATE; the
matroska-zero-length-block test has also been updated to cover
the infer_no_subs mode. The references for lots of other FATE tests
needed to be updated because of a newly added FlagDefault element with
value zero (whereas a FlagDefault with value 1 needn't be coded at all,
as it coincided with the default value of said element).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The Matroska specifications have evolved and now allow to mark
multiple tracks of the same kind as default (whether this was legal or
not before was dubious; e.g. mkvmerge disallowed it). Yet when the
Matroska muxer is set to infer default dispositions if absent, it also
enforced the now outdated restriction. So update this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The low overhead OBU format provides no means to resync after performing
a byte-based seek; in other words: Byte based seeking is just not
supported.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The av1_merge_frame BSF outputs its cached data when it sees the
beginning of a new frame, i.e. when it sees a temporal delimiter OBU.
Therefore it typically has a temporal delimiter OBU cached after
outputting a packet.
This implies that the OBU demuxer must flush its BSF upon seeking
because otherwise the first frame returned after a seek consists
of an old temporal delimiter OBU only.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It allows demuxers to perform certain tasks after
a successful generic seek.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The MOV muxer can store streamids as track ids but they aren't
visible when probing the result via lavf/dump or ffprobe due to
lack of this flag in the demuxer.
because subtitles streams will be written to webvtt m3u8 list
so the stream index should minus subtitles streams count when subtitle
between audio and video streams.
testcase:
before patch:
ffmpeg -i input -map 0🅰️0 -map 0:s:0 -map 0✌️0 -f hls aaaa.m3u8
will EXC_BAD_ACCESS
after patch:
ffmpeg -i input -map 0🅰️0 -map 0:s:0 -map 0✌️0 -f hls aaaa.m3u8
will ok
Signed-off-by: Steven Liu <liuqi05@kuaishou.com>
"frag_start" is redundant, and every occurance can be replaced with cluster[0].dts - start_dts
The proof of no behaviour changes: (All line number below is based on commit bff7d662d7)
"frag_start" is read at 4 place (with all possible call stacks):
mov_write_packet
...
mov_flush_fragment
mov_write_moof_tag
mov_write_moof_tag_internal
mov_write_traf_tag
mov_write_tfxd_tag (#1)
mov_write_tfdt_tag (#2)
mov_add_tfra_entries (#3)
mov_write_sidx_tags
mov_write_sidx_tag (#4)
mov_write_trailer
mov_auto_flush_fragment
mov_flush_fragment
... (#1#2#3#4)
mov_write_sidx_tags
mov_write_sidx_tag (#4)
shift_data
compute_sidx_size
get_sidx_size
mov_write_sidx_tags
mov_write_sidx_tag (#4)
All read happens in "mov_write_trailer" and "mov_write_moof_tag". So we need to prove no behaviour change in these two
functions.
Condition 1: for every track that have "trk->entry == 0", trk->frag_start == trk->track_duration.
Condition 2: for every track that have "trk->entry > 0", trk->frag_start == trk->cluster[0].dts - trk->start_dts.
Definition 1: "Before flush" means just before the invocation of "mov_flush_fragment", except for the auto-flush case in
"mov_write_single_packet", which means before L5934.
Lemma 1: If Condition 1 & 2 is true before flush, Condition 1 & 2 is still true after "mov_flush_fragment" returns.
Proof:
No update to the tracks that have "trk->entry == 0" before flushing, so we only consider tracks that have "trk->entry > 0":
Case 1: !moov_written and moov will be written in this iteration
trk->entry = 0 L5366
trk->frag_start == trk->cluster[0].dts - trk->start_dts Lemma condition
trk->frag_start += trk->start_dts + trk->track_duration - trk->cluster[0].dts; L5363
So trk->entry == 0 && trk->frag_start == trk->track_duration
Case 2: !moov_written and moov will NOT be written in this iteration
nothing changed
Case 3: moov_written
trk->entry = 0 L5445
trk->frag_start == trk->cluster[0].dts - trk->start_dts Lemma condition
trk->frag_start += trk->start_dts + trk->track_duration - trk->cluster[0].dts; L5444
So trk->entry == 0 && trk->frag_start == trk->track_duration
Note that trk->track_duration may be updated for the tracks that have "trk->entry > 0" (mov_write_moov_tag will
update track_duration of "tmcd" track, but it must have 1 entry). But in all case, trk->frag_start is also updated
to consider the new value.
Lemma 2: If Condition 1 & 2 is true before "ff_mov_write_packet" invocation, Condition 1 & 2 is still true after it returns.
Proof:
Only the track corresponding to the pkt is updated, and no update to relevant variables if trk->entry > 0 before invocation.
So we only need to prove "trk->frag_start == trk->cluster[0].dts - trk->start_dts" after trk->entry increase from 0 to 1.
Case 1: trk->start_dts == AV_NOPTS_VALUE
Case 1.1: trk->frag_discont && use_editlist
trk->cluster[0].dts = pkt->dts at L5741
trk->frag_start = pkt->pts at L5785
trk->start_dts = pkt->dts - pkt->pts at L5786
So trk->frag_start == trk->cluster[0].dts - trk->start_dts
Case 1.2: trk->frag_discont && !use_editlist
trk->cluster[0].dts = pkt->dts at L5741
trk->frag_start = pkt->dts at L5790
trk->start_dts = 0 at L5791
So trk->frag_start == trk->cluster[0].dts - trk->start_dts
Case 1.3: !trk->frag_discont
trk->cluster[0].dts = pkt->dts at L5741
trk->frag_start = 0 init
trk->start_dts = pkt->dts at L5779
So trk->frag_start == trk->cluster[0].dts - trk->start_dts
Case 2: trk->start_dts != AV_NOPTS_VALUE
Case 2.1: trk->frag_discont
trk->cluster[0].dts = pkt->dts at L5741
trk->frag_start = pkt->dts - trk->start_dts at L5763
So trk->frag_start == trk->cluster[0].dts - trk->start_dts
Case 2.2: !trk->frag_discont
trk->cluster[0].dts = trk->start_dts + trk->track_duration at L5749
trk->track_duration == trk->frag_start Lemma condition
So trk->frag_start == trk->cluster[0].dts - trk->start_dts
Lemma 3: Condition 1 & 2 is true in all case before and after "ff_mov_write_packet" invocation, before flush and after
"mov_flush_fragment" returns.
Proof: All updates to relevant variable happen either in "ff_mov_write_packet", or during flush. And Condition 1 & 2
is true initially. So with lemma 1 & 2, we can prove this use induction.
Noticed that all read of "frag_start" only happen in "trk->entry > 0" branch. Now we need to prove Condition 2 is true
before each read.
Because no update to variables relevant to Condition 2 between "before flush" and "mov_write_moof_tag" invocation, we
can conclude Condition 2 is true before every invocation of "mov_write_moof_tag". No behaviour change in
"mov_write_moof_tag" is proved.
In "mov_write_trailer", No update to relevant variables after the last flush and before the invocation of
"mov_write_sidx_tag". So no behaviour change to "mov_write_trailer" is proved.
Q.E.D.
Signed-off-by: Hu Weiwen <sehuww@mail.scut.edu.cn>
Signed-off-by: Martin Storsjö <martin@martin.st>
track->mdat_buf can be not NULL while the track is still empty if the
last packet write failed.
Signed-off-by: Hu Weiwen <sehuww@mail.scut.edu.cn>
Signed-off-by: Martin Storsjö <martin@martin.st>
In 1c42fd9323 the ipcm identifier was
added in order to demux additional raw audio from Sony MP4 files.
Unfortunately, it was not noticed that this same list is utilized
for muxing as well, thus causing ipcm to get preferred compared
to the identifier officially specified in QTFF documentation.
This fixes the order of preference for 24bit PCM, where ipcm is
still allowed, but in24 is the first match - thus being preferred.
Fixes fate-acodec-pcm-s24be.
Partition struct may be reallocated, so let's store the score directly in order
to avoid use-after-free.
Also mxf->current_partition might be null when reading some local tags.
Signed-off-by: Marton Balint <cus@passwd.hu>
If autoflushing on a new packet (e.g. due to the frag_every_frame
flag being set), there's no samples to be written in the new fragment,
so we can't overwrite the track duration in order to make it line
up with the next packet to be written.
Signed-off-by: Martin Storsjö <martin@martin.st>
av_dict_copy() puts the onus on the caller to clean up dst on failure;
it can be nonempty if copying a later entry of src fails after having
successfully copied an earlier entry.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
As the second argument for init_get_bits (buf) can be crafted, a return value check for this function call is necessary.
'buf' is part of 'AVPacket pkt'.
replace init_get_bits with init_get_bits8.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Infinite loop
Fixes: 36311/clusterfuzz-testcase-minimized-ffmpeg_dem_WTV_fuzzer-4889181296918528
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: signed integer overflow: 9223372036854775791 + 18 cannot be represented in type 'long'
Fixes: 36307/clusterfuzz-testcase-minimized-ffmpeg_dem_MPC8_fuzzer-4917863877050368
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
