Besides the obvious advantages this also fixes a potential memleak:
If only one of the arrays had been successfully allocated, the other
would leak. This also fixes Coverity issues #1440386 and #1440387.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Write a few numbers directly via AV_WB32 instead of using an AVIOContext
(that is initialized only for this very purpose) to write these numbers
at known offsets into a fixed buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
The Matroska Projection master element has such a small maximum length
that it can always be written with a length field of length one.
So it is unnecessary to first write the element into a dynamic buffer to
get the accurate length in order not to waste bytes on the length field.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
avformat/mux: Don't use av_ prefix for static functions
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
A score of 0 is possible Fixes: Ticket8500 Reviewed-by: Paul B Mahol <onemda@gmail.com> Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If no error occurs and this AVPacketList is used at all, its packet
substructure will be overwritten and its next pointer explicitly set, so
every field will still be initialized even when using av_malloc.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In the common case that the input packet was already refcounted,
ff_interleave_add_packet would allocate a new AVPacketList, use
av_packet_ref to create a new reference to the buffer for the
AVPacketList's packet, interleave the packet and finally unreference
the original input packet.
This commit changes this: It uses av_packet_move_ref to transfer
the packet to its destination. In case the input packet is refcounted,
this saves an allocation and a free (of an AVBufferRef); if not, the
packet is made refcounted before moving it. When the input packet has
side data, one saves even more than one allocation+free.
Furthermore, when the packet is in reality an uncoded frame, a hacky
ad-hoc variant of av_packet_move_ref has been employed. Not any more.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avformat/audiointerleave: Check before dereferencing
In order to use ff_audio_rechunk_interleave() (a special interleavement
function for situations where the ordinary "interleave by dts" is not
appropriate), the AVStreams must have private data and this private data
must begin with an AudioInterleaveContext which contains a fifo that may
need to be freed and when ff_audio_interleave_close() was called, it just
assumed that everything has been properly set up, i.e. that every streams
priv_data exists. This implies that this function can not be called from
the deinit function of a muxer, because such functions might be called
if the private data has not been successfully allocated. In order to
change this, add a check for whether the private data exists before
trying to free the fifo in it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The muxing context has already been zeroed when it was allocated, hence
it is unnecessary to do it again.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avformat/dvenc: Replace write_trailer by deinit function
The old write_trailer only freed memory, so it is better to make a
dedicated deinit function out of it. Given that this function will also
be called when writing the header fails, one can also remove code that
frees already allocated fifos when allocating another one fails.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avformat/av1: Avoid allocation + copying when filtering OBUs
Certain types of OBUs are stripped away before muxing into Matroska and
ISOBMFF; there are two functions to do this: One that outputs by
directly writing in an AVIOContext and one that returns a freshly
allocated buffer with the units not stripped away copied into it.
The latter option is bad for performance, especially when the input
does already not contain any of the units intended to be stripped away
(this covers typical remuxing scenarios). Therefore this commit changes
this by avoiding allocating and copying when possible; it is possible if
the OBUs to be retained are consecutively in the input buffer (without
an OBU to be discarded between them). In this case, the caller receives
the offset as well as the length of the part of the buffer that contains
the units to be kept. This also avoids copying when e.g. the only unit
to be discarded is a temporal delimiter at the front.
For a 22.7mb/s file with average framesize 113 kB this improved the time
for the calls to ff_av1_filter_obus_buf() when writing Matroska from
313319 decicycles to 2368 decicycles; for another file with 1.5mb/s
(average framesize 7.3 kB) it improved from 34539 decicycles to 1922
decicyles. For these files the only units that needed to be stripped
away were temporal unit delimiters at the front.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
ff_av1_filter_obus_buf() and ff_avc_parse_nal_units_buf() both have a
pointer-to-pointer parameter which they use to pass a newly allocated
buffer to the caller. And both functions freed what this pointer points to
before overwriting it. But no caller of these functions used this feature,
but some had to initialize the pointer just because of this. So remove
it and update the documentation of ff_av1_filter_obus_buf() wrt this fact.
ff_hevc_annexb2mp4_buf in contrast did not free the pointer. This has been
documented, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
Both ISOBMFF as well as Matroska require certain OBUs to be stripped
before muxing them. There are two functions for this purpose; one writes
directly into an AVIOContext, the other returns a freshly allocated
buffer with the undesired units stripped away.
The latter one actually relies on the former by means of a dynamic
buffer. This has several drawbacks: The underlying buffer might have to
be reallocated multiple times; the buffer will eventually be
overallocated; the data will not be directly copied into the final
buffer, but rather first in the write buffer (in chunks of 1024 byte)
and then written in these chunks. Moreover, the API for dynamic buffers
is defective wrt error checking and as a consequence, the earlier code
would indicate a length of -AV_INPUT_BUFFER_PADDING_SIZE on allocation
failure, but it would not return an error; there would also be no error
in case the arbitrary limit of INT_MAX/2 that is currently imposed on
dynamic buffers is hit.
This commit changes this: The buffer is now parsed twice, once to get
the precise length which will then be allocated; and once to actually
write the data.
For a 22.7mb/s file with average framesize 113 kB this improved the time
for the calls to ff_av1_filter_obus_buf() when writing Matroska from
753662 decicycles to 313319 decicycles (based upon 50 runs a 2048 frames
each); for another 1.5mb/s file (with average framesize of 7.3 kB) it
improved from 79270 decicycles to 34539 decicycles (based upon 50 runs a
4096 frames).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
avformat/av1, hevc: Make *_buf-functions return 0 on success
The output size is already returned via a pointer argument, so there is
no need to return it via the ordinary return value as well. The
rationale behind this is to not poison the return value on success.
It also unifies the behaviour of the *_buf-functions for AVC, AV1 and
HEVC.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
avformat/hevc: Fix potential leak in case of ff_hevc_annexb2mp4_buf failure
ff_hevc_annexb2mp4_buf() could indicate an error, yet leave cleaning
after itself to the caller, so that a caller could not simply return the
error, but had to free the buffer first.
(Given that all current callers have set filter_ps = 0, this error can
currently not be triggered.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
avformat/matroskaenc: Check for reformatting errors
This is needed especially for AV1: If a reformatting error happens (e.g.
if the length field of an OBU contained in the current packet indicates
that said OBU extends beyond the current packet), the data pointer is
still NULL, yet the size is unchanged, so that writing the data leads
to a segmentation fault.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
Marton Balint [Tue, 14 Jan 2020 18:18:01 +0000 (19:18 +0100)]
avformat/udp: increase the default buffer size of a receiving socket to 384K
It is a common mistake that people only increase fifo_size when they experience
drops, unfortunately this does not help for higher bitrate (> 100 Mbps) streams
when the reader thread simply might not receive the packets in time (especially
under high CPU load) if the default 64 KB of kernel buffer size is used.
New default is determined so that common linux systems can set this buffer size
without tuning kernel parameters.
Martin Storsjö [Tue, 21 Jan 2020 12:47:57 +0000 (14:47 +0200)]
configure: Check for GetStdHandle in addition to SetConsoleTextAttribute
SetConsoleTextAttribute used to be unavailable for Windows Store apps,
but is available to them now. But GetStdHandle still is unavailable,
thus make sure to check for both functions before using code that
requires both.
Andriy Gelman [Sat, 11 Jan 2020 04:25:26 +0000 (23:25 -0500)]
avformat/libzmq: Replace fail statements with goto
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com> Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Replace "(a * (1 << shift) * b + c) >> shift" by "a * b + (c >> shift)".
It is equivalent to the old code because a is in the range of uint16_t,
shift is 12 and b is effectively a signed 4-bit number, so that no
overflow/truncation of high bits happens during the multiplication
(overflow would be undefined anyway).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/adxenc: Avoid undefined left shift of negative numbers
Replace "((a << shift) + b) >> shift" by "a + (b >> shift)". This avoids
a left shift which also happens to trigger undefined behaviour in case "a"
is negative. This affected the FATE-tests acodec-adpcm-adx and
acodec-adpcm-adx-trellis; it also fixes ticket #8008.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Bela Bodecs [Sun, 19 Jan 2020 22:01:32 +0000 (23:01 +0100)]
avformat/hlsenc: fix default AES key file url with variant streams
Currently when hls_enc is active and there are multiple variant stream
outputs, default key file url construction does not work, because it is
based on the FormatContext' url field. But in case of multiple variant
streams, it contains the variant m3u8 output playlist url that contains
the %v placeholder. So the result key file url will hold the %v
placeholder causing run time error message about "could not write the
key file".
This patch correct this behaviour, and use the master playlist url for
constructing the output key file url when master playlist is vailable.
Bela Bodecs [Sat, 18 Jan 2020 16:41:55 +0000 (17:41 +0100)]
avformat/hlsenc: program_date_time and append_list flags conflict
When program_date_time flag is present, in m3u8 playlist file each
segment has a corresponding EXT-X-PROGRAM-DATE-TIME value. The intial
program-date-time value is the actual current time at init and
each new segment increments this value by its duration. When append_list
flags is also present, existing playlist parsing by hls_append_segment
treats existing segments as new segments regarding the program-date-time
calculation. But it should not do that, because this way all real the
new segments' EXT-X-PROGRAM-DATE-TIME values will be shifted erroneously
by the sum duration of existing segments. Instead it should have
decremented the initial program-date-time value by its duration. This
would ensure that
the first new segment's program-date-time value had the current time as
it is expected.
This patch corrects this behaviour and prevent existing segments to
increment the value of initial_prog_date_time variable but decrements
it.
Reviewed-by: Steven Liu <lq@onvideo.cn> Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
projects / ffmpeg / log