recvfrom() is not a cancellation point in pthreads-win32, see
https://sourceware.org/pthreads-win32/manual/pthread_cancel.html
In order to be able to cancel the reader thread on Win32 properly we first
shutdown the socket then call CancelIoEx to abort pending IO. Subsequent
recvfrom() calls will fail with WSAESHUTDOWN causing the thread to exit.
Fixes ticket #5717.
Signed-off-by: Marton Balint <cus@passwd.hu>
this usecase will cause a division by zero trap:
1. dashenc has received one frame
2. os->max_pts and os->start_pts have same value
3. delta between max_pts and start_pts is 0
4. av_rescale_q(0, x, y) returns 0
5. this value is used as denominator in division
6. Bang! -> segfault
this fix checks that max_pts > start_pts.
the fix has been tested and works.
Signed-off-by: Alfred E. Heggestad <alfred.heggestad@gmail.com>
Reviewed-by: Jeyapal, Karthick <kjeyapal@akamai.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: bypassing of checks and assertion failure
Fixes: asan_1003879.mp4
Found-by: Clusterfuzz + asan
Reported-by: Thomas Guilbert <tguilbert@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In the Libav commit cae448cf, the opaque of every AVIOContext opened
by ffio_fdopen() (which is used internally by avio_open() and avio_open2())
changed: It was a simple pointer to an URLContext before, but now it was
a structure (namely AVIOInternal) containing a pointer to an URLContext
as its only member. The next commits (namely 8c0ceafb and ec4c4839) added
members to AVIOInternal to allow white-/blacklisting of protocols.
But these two commits were never merged into FFmpeg (they were only
merged as no-ops in 510046c2 and 063b26d3), because FFmpeg chose
a different way to implement this (in 93629735); and so our AVIOInternal
still has exactly one member.
This of course means that it is unnecessary to use AVIOInternal as
opaque as it is just adding a level of indirection (not only pointer
dereference, but also wrapper functions). Therefore this commit
removes AVIOInternal entirely and essentially reverts cae448cf.
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>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Suggested-by: Hendrik Leppkes <h.leppkes@gmail.com>
Suggested-by: Nicolas George <george@nsup.org>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Fixes memleak and Coverity issue #1439587.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@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>
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>
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>
Fixes memleaks when the trailer is never written (e.g. if the call to
gxf_write_map_packet() at the end of gxf_write_header() fails).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes memleaks when allocating the private data of the timecode_track
fails or when the trailer is never written.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It will be freed when the AVStream is freed later anyway.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
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>
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>
If this is not done, the avio_write() calls will cause segfaults
immediately afterwards on error.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
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>
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>
Add {, } in situations like
if ()
...
else if ()
/* Comment */
...
else ...
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
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>
Adds support for the custom ASF container used by some Argonaut Games'
games, such as 'Croc! Legend of the Gobbos', and 'Croc 2'.
Can also handle the sample files in:
https://samples.ffmpeg.org/game-formats/brender/part2.zip
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
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.
Signed-off-by: Marton Balint <cus@passwd.hu>
As per the PIFF standard, the timescale of 10000000
is recommended but not mandatory, so don't override
the user-set value.
A warning is shown for non-recommended values.
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>
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.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
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>
fix ticket: 8461
there is no problem before commit 75aea52a10
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Also simplify it and make it always log the error.
This fixes for example the image2 muxer when used with an URL which also
contains the protocol:
ffmpeg -f lavfi -i testsrc -vframes 10 -atomic_writing 1 file:out%d.png
Signed-off-by: Marton Balint <cus@passwd.hu>
As written in https://github.com/Haivision/srt/blob/v1.4.1/docs/API.md,
the nonblock mode is activated if SRTO_SNDSYN and SRTO_RCVSYN, for
sending and receiving respectively, are set to 0.
Signed-off-by: Marton Balint <cus@passwd.hu>
Both S16LE as well as DTS can have lots of 0 bytes in silent segments
Using these results in error. Thus this patch skips 0 bytes in
comparission.
Fixes Ticket6561
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This will likely also fix CID 1452427, a false positive resulting from
Coverity thinking that av_dict_set() automatically frees its key and
value parameters (even without the AV_DICT_DONT_STRDUP_* flags).
(AV_DICT_APPEND and AV_DICT_DONT_STRDUP_VAL are compatible with each
other since a8c5b455, so we can reset this flag here. It has originally
been removed in 0dc66553 when appending was added.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When shifting the already written data in order to write the keyframe
index, the flv muxer would first store the pre-shift size, then
calculate how big the index will be eventually, then perform some seeks
to update some size fields, then seek back to the end of the file to get
the new position, followed by a seek to the position where writing will
really start. Seeking back to the (already known) end position (that is
actually used to perform this seek) to get the end position is of course
unnecessary. It has been removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When the faststart option for the mov/mp4 muxer is used, the current
position (i.e. the size of the already written data pre-shifting) was
evaluated twice: First in an initialization and then again later,
overwriting the first value without having ever touched it. So remove
the initialization.
Also, the clone of this code in the Sega FILM muxer behaves the same and
has been treated the same.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
s337m_get_offset_and_codec does not make use of
AVFormatContext: AVClass is enough for logging.
Will facilitate further use from outside
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Allows to set an intended target latency while streaming that clients can use
to measure when using low latency mode.
Signed-off-by: James Almer <jamrial@gmail.com>
In combination with the streaming option it constrains the value of a few elements,
to prevet clients from buffering too much data before starting presentation.
Signed-off-by: James Almer <jamrial@gmail.com>
If not available, set flags to 24 (bits 4 and 5), to signal the wallclock value
is read at the time of writing the atom.
Signed-off-by: James Almer <jamrial@gmail.com>
Implemented as as a frag_duration muxer option and key=value entry in the
adaptation_sets muxer option. It has the same syntax as the seg_duration option.
A new frag_type option is also introduced to select the kind of fragmentation.
Signed-off-by: James Almer <jamrial@gmail.com>
Implemented as as a seg_duration key=value entry in the adaptation_sets muxer
option.
It has the same syntax as the global seg_duration option, and has precedence
over it if set.
Signed-off-by: James Almer <jamrial@gmail.com>
Since bae8844e35, the packet is automatically unreferenced in
ff_read_packet() when an error is returned; but the documentation of
this of AVInputFormat.read_packet has not been updated accordingly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The current code only checks when writing the trailer whether the video
format and Codec ID are actually compatible with the container. At this
point, a lot of data will already have been written (in vain, of
course), so check during the init function instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Up until now, the Sega FILM muxer complained if the first stream wasn't a
video stream that there is no video stream at all which is of course
nonsense. So postpone this check.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
by changing the type to unsigned.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In order to indicate that the frames in a BlockGroup are not keyframes,
one has to add a ReferenceBlock element containing the timestamp of a
referenced Block that has already been written. The timestamp ought to be
relative to the timestamp of the Block it is attached to. Yet the
Matroska muxer used the relative timestamp of the preceding Block of the
track, i.e. the timestamp of the preceding block relative to the
timestamp of the Cluster containing said block (that need not be the
Cluster containing the current Block). This has been fixed.
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>
libavformat/img2.h: New field export_path_metadata to
VideoDemuxData to only allow the use of the extra metadata
upon explicit user request, for security reasons.
libavformat/img2dec.c: Modify image2 demuxer to make available
two special metadata entries called lavf.image2dec.source_path
and lavf.image2dec.source_basename, which represents, respectively,
the complete path to the source image for the current frame and
the basename i.e. the file name related to the current frame.
These can then be used by filters like drawtext and others. The
metadata fields will only be available when explicitly enabled
with image2 option -export_path_metadata 1.
doc/demuxers.texi: Documented the new metadata fields available
for image2 and how to use them.
doc/filters.texi: Added an example on how to use the new metadata
fields with drawtext filter, in order to plot the input file path
to each output frame.
Usage example:
ffmpeg -f image2 -export_path_metadata 1 -pattern_type glob
-framerate 18 -i '/path/to/input/files/*.jpg'
-filter_complex drawtext="fontsize=40:fontcolor=white:
fontfile=FreeSans.ttf:borderw=2:bordercolor=black:
text='%{metadata\:lavf.image2dec.source_basename\:NA}':x=5:y=50"
output.avi
Fixes#2874.
Signed-off-by: Alexandre Heitor Schmidt <alexandre.schmidt@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
This will likely also fix CID 1452574 and 1452565, false positives
resulting from Coverity thinking that av_dict_set() automatically
frees its key and value parameters (even without the
AV_DICT_DONT_STRDUP_* flags).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Keep all the existing data fields as they are (there's lots and
lots of nontrivial calculation and heuristics based on them in
their current form), but derive the duration as the difference
between the pts of the first packet to the maximum pts+duration
(not necessarily the last packet); use this duration in any box
where the actual presentation duration is supposed to be.
Fixes: 8420
Signed-off-by: Martin Storsjö <martin@martin.st>
If the size of the input packet is zero, av_grow_packet() used to call
av_new_packet() which would initialize the packet and (in particular)
reset the pos field. This behaviour (which was never documented and
arguably always contradicted the documented behaviour) was changed in
2fe04630. This means that it is unnecessary to save and restore the
packet's position in append_packet_chunked().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes#8314.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: James Almer <jamrial@gmail.com>
The Dash muxer uses submuxers and when one such submuxer has been allocated,
it is initially only stored in a temporary variable. Therefore it leaks
if an error happens between the allocation and storing it permanently.
This commit changes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: "Jeyapal, Karthick" <kjeyapal@akamai.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit improves returned error codes by forwarding error codes. In
some instances, the hardcoded returned error codes made no sense at all:
The normal error code for failure of av_new_packet() is AVERROR(ENOMEM),
yet there were instances where AVERROR(EIO) was returned.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
by freeing it a bit earlier.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Converting explicit avio_flush() calls helps us to buffer more data and avoid
flushing the IO context too often which causes reduced IO throughput for
non-streamed file output.
The user can control FLUSH_POINT flushing behaviour using the -flush_packets
option, the default typically means to flush unless a non-streamed file output
is used, so this change should have no adverse effect on streaming even if it
is assumed that after an avio_flush() the output buffer is clean so small
seekbacks within the output buffer will work even when the IO context is not
seekable.
Signed-off-by: Marton Balint <cus@passwd.hu>
These instances are simply redundant or present because avio_flush() used to be
required before doing a seekback. That is no longer the case, aviobuf code does
the flush automatically on seek.
This only affects code which is either disabled for streaming IO contexts or
does no seekbacks after the flush, so this change should have no adverse effect
on streaming.
Signed-off-by: Marton Balint <cus@passwd.hu>
Removing explicit avio_flush() calls helps us to buffer more data and avoid
flushing the IO context too often which causes reduced IO throughput for
non-streamed file output.
The user can control flushing behaviour at the end of every packet using the
-flush_packets option, the default typically means to flush unless a
non-streamed file output is used.
Therefore this change should have no adverse effect on streaming, even if it is
assumed that a new packet has a clean buffer so small seekbacks within the
output buffer work even when the IO context is not seekable.
Signed-off-by: Marton Balint <cus@passwd.hu>
To make it consistent with other muxers.
The user can still control the generic flushing behaviour after write_header
(same way as after packets) using the -flush_packets option, the default
typically means to flush unless a non-streamed file output is used.
Therefore this change should have no adverse effect on streaming, even if it is
assumed that the first packet has a clean buffer, so small seekbacks within the
output buffer work even when the IO context is not seekable.
Signed-off-by: Marton Balint <cus@passwd.hu>
The documentation of both avio_open() as well as avio_open2() states
that on failure, the pointer to an AVIOContext given to this function
(via a pointer to a pointer to an AVIOContext) will be set to NULL. Yet
it didn't happen upon failure of ffurl_open_whitelist() or when allocating
the internal buffer failed. This commit changes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This will likely also fix CID 1452562, a false positive resulting from
Coverity thinking that av_dict_set() automatically frees its key and
value parameters (even without the AV_DICT_DONT_STRDUP_* flags).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The Matroska muxer currently does not check the return value of
ff_isom_write_hvcc(), the function used to write mp4-style
HEVC-extradata as Matroska also uses it. This was intentionally done in
7a5356c72 to allow remuxing from mpeg-ts.
But if ff_isom_write_hvcc() fails, it has not output anything and the
file ends up without CodecPrivate and, if the input was Annex B, with
Annex B data, which is against the spec. So check the return value
again.
The underlying issue of not having extradata seems to have been fixed by
the introduction of the extract_extradata bitstream filter.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: "mypopy@gmail.com" <mypopy@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
to its actual behaviour: That it uses the least amount of bytes unless
overridden.
The current documentation leaves it undefined how many bytes will be used
when no number to use has been given explicitly. But several estimates
(used to write EBML Master elements with a small length field) require
this number to be the least amount of bytes to work. Therefore change
the documentation; and remove a comment about writing length fields
indicating "unkown length". It has been outdated since 0580a122.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When vobsub_read_packet() reads a packet, it uses a dedicated AVPacket
to get the subtitle timing and position from an FFDemuxSubtitlesQueue
(which has been filled with this data during reading the idx file in
vobsub_read_header); afterwards the actual subtitle data is read into
the packet destined for output and the timing and position are copied
to this packet. Afterwards, the local packet is unreferenced.
This can be simplified: Simply use the output packet to get the timing
and position from the FFDemuxSubtitlesQueue. The packet's size will be
zero afterwards, so that it can be directly used to read the actual
subtitle data. This makes copying the packet fields as well as
unreferencing the local packet unecessary and also removes an instance
of usage of sizeof(AVPacket) in libavformat.
The only difference is that the returned packet will already be flagged
as a keyframe. This currently only happens in compute_pkt_fields().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When a Matroska Block is only stored in compressed form, the size of
the uncompressed block is not explicitly coded and therefore not known
before decompressing it. Therefore the demuxer uses a guess for the
uncompressed size: The first guess is three times the compressed size
and if this is not enough, it is repeatedly incremented by a factor of
three. But when this happens with lzo, the decompression is neither
resumed nor started again. Instead when av_lzo1x_decode indicates that x
bytes of input data could not be decoded, because the output buffer is
already full, the first (not the last) x bytes of the input buffer are
resent for decoding in the next try; they overwrite already decoded
data.
This commit fixes this by instead restarting the decompression anew,
just with a bigger buffer.
This seems to be a regression since 935ec5a1.
A FATE-test for this has been added.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
When the user decides they do not want to to send the Icy-MetaData
header, this should be respected for all requests, not just the first
one.
Fix#5578
Reviewed-by: Liu Steven <lq@chinaffmpeg.org>
Signed-off-by: James Almer <jamrial@gmail.com>
When the user decides they do not want to to send the Icy-MetaData
header, this should be respected for all requests, not just the first
one.
Fix#5578
Reviewed-by: Liu Steven <lq@chinaffmpeg.org>
Signed-off-by: James Almer <jamrial@gmail.com>
Up until now, the microdvd demuxer uses av_strdup() to allocate the
extradata from a string; its length is set to strlen() + 1, i.e.
including the \0 at the end. Upon remuxing, the muxer would simply copy
the extradata at the beginning, including the \0.
This commit changes this by not adding the \0 to the size of the
extradata; the muxer now delimits extradata by inserting a \n. This
required to change the subtitles-microdvd-remux FATE-test.
Furthermore, the extradata is now allocated with zeroed padding.
The microdvd decoder is not affected by this, as it didn't use the size
of the extradata at all, but treated it as a C-string.
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>
Might happen for annex B H.264.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
While the function adding a new element to the keyframe index checked
the allocation, the caller didn't check the return value. This has been
changed. To do so, the return value has been changed to an ordinary ret
instead of pb->error. This doesn't pose a problem, as write_packet() in
mux.c already checks for write errors (since 9ad1e0c1).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The write_trailer function doesn't write anything anyway. It only frees
memory.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The MPEG-TS muxer will mux streams with unsupported codec id
as a private data stream; this usually makes the stream
not recognizable by ffmpeg and likely other tools.
When a parameter like e.g. language is contained more than once in the
part of var_stream_map pertaining to a single VariantStream, the later
one just overwrites the pointer to the earlier one, leading to a
memleak. This commit changes this by handling the situation gracefully:
The earlier string is silently freed first, so that the last one wins.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Steven Liu <lq@onvideo.cn>
"If an error is detected, localtime_r() shall return a null pointer
and set errno to indicate the error." Yet in case this happened in
hls_init(), AVERROR(ENOMEM) has been returned.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Steven Liu <lq@onvideo.cn>
The hls muxer allocates an array of VariantStreams, a structure that
contains pointers to objects that need to be freed on their own. This
means that the number of allocated VariantStreams needs to be correct
when they are freed; yet the number of VariantStreams is set in
update_variant_stream_info() resp. parse_variant_stream_mapstring()
before the allocation has been checked for success, so that upon error
an attempt would be made to free the objects whose pointers are
positioned at position NULL (the location of VariantStreams) +
offsetof(VariantStream, the corresponding pointer).
Furthermore d1fe1344 added another possibility for the first function
to leave an inconsistent state behind: If an allocation of one of the
objects referenced by the VariantStream fails, the VariantStream will be
freed, but the number of allocated VariantStreams isn't reset, leading
to the same problem as above. (This was done in the mistaken belief that
the VariantStreams array would leak otherwise.)
Essentially the same also happens for the number of cc-streams. It has
been fixed, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Steven Liu <lq@onvideo.cn>
Under certain circumstances hls_write_packet() would add options to an
AVDictionary. Said dictionary was never explicitly freed, instead it was
presumed that these options would be consumed when opening a new
IO-context. This left several possibilities for memleaks:
a) When no new IO-context would be opened at all. This is possible when
using both the flags temp_file and single_file together with a file
output.
b) When an error happens before one actually tries to open the new
IO-context.
c) When the new IO-context does not consume all options.
All three have been fixed; furthermore, the AVDictionary has been put
into a smaller scope (namely the only part of hls_write_packet() where
it is actually used).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Steven Liu <lq@onvideo.cn>
hls_mux_init() currently leaks an AVDictionary if opening a dynamic
buffer fails or if avformat_init_output fails. This has been fixed by
moving the initialization resp. the freeing of the dictionary around:
In the former case to a place after opening the dynamic buffer, in the
latter to a place before the check for initialization failure so that it
is done unconditionally.
Furthermore, the dictionary is now only copied and freed if the options
in it are actually used (namely when in SEGMENT_TYPE_FMP4 mode).
Finally, a similar situation in hls_start() has been fixed, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Steven Liu <lq@onvideo.cn>
hls_init() would allocate a buffer, although it is only needed in one of
two branches that follow. This commit moves the allocation to the branch
that actually needs the buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Steven Liu <lq@onvideo.cn>
Before ed897633, the hls muxer would free its child AVFormatContexts
and reset the pointer to these contexts to NULL immediately afterwards;
ed897633 moved the former to later (into a separate function), but kept
the resetting, ensuring that the child context leaks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Steven Liu <lq@onvideo.cn>
This will probably also fix CID 1452559, a false positive where Coverity
claims a double-free occurs, because it thinks that av_dict_set() frees
its key and value arguments even when the AV_DICT_DONT_STRDUP_* flags
aren't used.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Marvin Scholz <epirat07@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In case an AVBPrint was not complete, icecast_open() would free some
buffers that have not been allocated yet instead of freeing the data of
the AVBPrint (if they have been allocated). Because this error does not
trigger a jump to the general cleanup section any more, one can moreover
remove a (now unnecessary) initialization of a pointer.
Furthermore, finalizing an AVBPrint can fail (namely when the string
inside the AVBPrint has not been allocated yet) and so this needs to be
checked.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
They have been removed altogether without a compat implementation, and are
either no-ops or return NULL.
This fixes compiler warnings about checks always evaluating to false, and leaks
of allocated mutexes.
Signed-off-by: James Almer <jamrial@gmail.com>
These functions already free it themselves before they allocate the new
extradata.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It is not uncommon to find code where the caller thinks to know better
what the return value should be than the callee. E.g. something like
"if (av_new_packet(pkt, size) < 0) return AVERROR(ENOMEM);". This commit
changes several instances of this to instead forward the actual error.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
