A failure in segment_end() or segment_start() would lead to freeing
a dangling pointer and in general further calls to seg_write_packet()
or to seg_write_trailer() would have the same faulty behaviour.
CC: libav-stable@libav.org
Reported-By: luodalongde@gmail.com
I think this turned out pretty terrible. There's no good way to add new
custom tags that write to AVFormatContext->metadata.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The previous code assumed if an atom was marked with a 64-bit
size extension, it actually had that data available. The new
code verfies there's enough data in the atom for this to be
done.
Failure to verify causes total_size > atom.size which will
result in negative size calculations later on.
Found-by: Paul Mehta <paul@paulmehta.com>
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Under abnormal conditions the item_count may exceed the max
allocation size on 32-bit systems, this causes the allocated
size to overflow and become too small for the given count.
Additionally, if av_reallocp() fails its allocation, the
fragment_index_count is not correctly decremented.
Ensuring further havoc may be wrought, the error code for
read_tfra() is not checked upon return.
Found-by: Paul Mehta <paul@paulmehta.com>
positive return code and use of _array functions by commiter
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
ID3v1 fields have a fixed size, and they are padded either with zeros,
or with spaces. Handle the latter case, instead of putting strings with
trailing spaces into the AVDictionary.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '46808fdf04ab113df374157b90b506eb3110daf2':
movenc: Enable editlists by default if delay_moov is enabled
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This comment can be traced back to the initial commit from 2001,
and it seemed to be misleading/incorect already back then. (It
was used for normal, non-raw file formats already then.)
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'b3b0b35db2f3b61bf2f0f4fa85f5b6267d83c8fe':
movenc: Get rid of a hack for updating the dvc1 atom
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '847bf5988fec1d3e65c1d8cf0cdb8caf0cfd0c1b':
movenc: Add an option for delaying writing the moov with empty_moov
Conflicts:
libavformat/movenc.c
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'c725faebda9a516766d94c33b07972ab0f70cf93':
movenc: Use start_dts/cts instead of cluster[0] for writing edit lists
Conflicts:
libavformat/movenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '724cbea7193945fe5a5b4dea8ede344803572844':
movenc: Remove an unnecessary condition when flushing fragments
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '355d01a1bf55297b1d1f04e4bfbf0ddc93b6247e':
movenc: Factorize writing ftyp and other identification tags to a separate function
Conflicts:
libavformat/movenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This should be more correct. This also should give more sensible
switching between video streams with different amount of b-frame
delay.
The current dash.js release (1.2.0) fails to start playback of
such files from the start (if the start pts is > 0), but this has
been fixed in the current git version of dash.js.
Also enable the use of edit lists, so that streams in many cases
start at pts=0.
Signed-off-by: Martin Storsjö <martin@martin.st>
Use the more generic approach with the delay_moov flag, instead of
having a update mechanism specific to this one single atom.
Signed-off-by: Martin Storsjö <martin@martin.st>
This delays writing the moov until the first fragment is written,
or can be flushed by the caller explicitly when wanted. If the first
sample in all streams is available at this point, we can write
a proper editlist at this point, allowing streams to start at
something else than dts=0. For AC3 and DNXHD, a packet is
needed in order to write the moov header properly.
This isn't added to the normal behaviour for empty_moov, since
the behaviour that ftyp+moov is written during avformat_write_header
would be changed. Callers that split the output stream into header+segments
(either by flushing manually, with the custom_frag flag set, or by
just differentiating between data written during avformat_write_header
and the rest) will need to be adjusted to take this option into use.
For handling streams that start at something else than dts=0, an
alternative would be to use different kinds of heuristics for
guessing the start dts (using AVCodecContext delay or has_b_frames
together with the frame rate), but this is not reliable and doesn't
necessarily work well with stream copy, and wouldn't work for getting
the right initialization data for AC3 or DNXHD either.
Signed-off-by: Martin Storsjö <martin@martin.st>
