Current muxers only use a single bitstream filter, so there is no need to
maintain code which operates on a list of bitstream filters. When multiple
bitstream filters are needed muxers can simply use a list bitstream filter.
If there is a use case in the future when different bitstream filters should be
added at subsequent packets then a new API possibly involving reconfiguring the
list bitstream filter can be added knowing the exact requirements.
Signed-off-by: Marton Balint <cus@passwd.hu>
stdarg.h has been included in 780d7897a9
for ff_url_join(). This header became unnecessary when this function was
moved into a separate file in df9f22d42b.
libavutil/pixdesc.h has been included for av_get_pix_fmt_name() in
603b8bc2a1 and is unused since commit
2fb7501938 that removed the stuff belonging
to FF_API_FORMAT_PARAMETERS. Notice that this file still uses
AV_PIX_FMT_NONE and that therefore the header libavutil/pixfmt.h has
been included (this header is included in pixdesc.h as well as also in
libavutil/internal.h which is also included).
libavutil/time_internal.h has been included for gmtime_r() in commit
e7dd97b5d8cd6ea150446591f37a5946e8ab7cfb; it is unused since commit
b72a7b96f8 which basically moved the code
making use of gmtime_r() to libavutil/dict.c to use in
avpriv_dict_set_timestamp().
audiointerleave.h has been added in c26e58e32c
because of ff_interleave_compare_dts() (at that time the muxing code
was not split from utils.c yet); said function became static in commit
101e1f6ff9, making this header redundant.
metadata.h has been mostly included for what now resides in
libavutil/dict.h. The stuff that now resides in metadata.h has only been
used briefly: From commits ed7694d8cf to
d60a9f52eb.
riff.h has been added in 45da8124a0
because riff.h once contained declarations for (ff_)codec_get_tag().
This was changed in bfe5454cd2.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat_find_stream_info() may decode some frames to get stream
information. And when it does this for subtitles, the decoded subtitles
leak.
(Decoding subtitles was added in b1511e00f6
for PGS subtitles. When PGS subtitles originate from a container that
exports every segment as a packet of its own, no output will be
generated when decoding a packet, because not enough input is available.
Yet when used with PGS subtitles in the Matroska form a single packet
contains enough data to generate output. Yet said output is not freed,
hence this leak.)
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Such errors may make sense for specific formats, but general parsing
logic shouldn't be treating these as errors regardless of the error
recognition mode.
Fixes loading of the following wave when using -err_detect explode:
https://cs.chromium.org/chromium/src/third_party/blink/web_tests/external/wpt/webaudio/resources/4ch-440.wav
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 2045163756 * 2 cannot be represented in type 'int'
Fixes: Ticket5132
Found-by: tsmith
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
RFC 3986 states that the generic syntax uses the slash ("/"), question mark
("?"), and number sign ("#") characters to delimit components that are
significant to the generic parser's hierarchical interpretation of an
identifier.
Signed-off-by: Marton Balint <cus@passwd.hu>
A demuxer might have allocated memory while reading the header. If
reading the header was successfull and an error happens before returning
(e.g. when queueing the attached pictures), the read_close function
would have never been called, so that all those allocations would leak.
This commit changes this.
Furthermore, there would be even more memleaks if the error level was
set to AV_EF_EXPLODE in case there is both metadata and id3v2 metadata.
This has been fixed, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
When e2_pts == INT64_MIN and e1_pts >= 0 the calculation of
e2_pts - e1_pts will overflow an int64_t.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
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>
Introduce AV_CODEC_PROP_INTRA_ONLY flag to audio codec as well as video codec to support non intra-only audio codec.
Signed-off-by: Yuki Tsuchiya <Yuki.Tsuchiya@sony.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Allows user to set maximum number of buffered packets when
probing a codec. It was a hard-coded parameter before this commit.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Despite the doxy stating that it's called when the muxer is destroyed,
this was not true in practice. It's only called by av_write_trailer()
and on init() failure.
An AVFormatContext may be closed without writing the trailer if errors
ocurred while muxing packets, so in order to prevent memory leaks, it
should effectively be called when freeing the muxer.
Signed-off-by: James Almer <jamrial@gmail.com>
add new function duration_estimate_name to dump duration estimate
method, it's will help to debug some duration issue.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
change the log level to warning if can't get duration, it's will help
to debug some duration issue
Signed-off-by: vacingfang <vacingfang@tencent.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Up until now, read_frame_internal always initialized the packet it
received. But since the recent changes to ff_read_packet, this is no
longer needed: If the parsing queue is initially empty upon entering
read_frame_internal, the packet will now either contain content upon
success or be blank upon failure of ff_read_packet. If the parsing
queue is initially not empty, the packet will be overwritten with the
oldest one from the parsing queue.
Similarly, it is unnecessary to initialize ret in read_frame_internal.
In parse_packet, it is easily possible to only initialize the packet
used as temporary storage for the output if said packet is used at all;
furthermore, this packet doesn't need to be zero-initialized, because
av_init_packet will initialize every field except size and data and
those fields will be set by av_parser_parse2.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, parse_packet() used a stack packet in case the stream is
flushed. But using such a packet is unnecessary as there is an AVPacket
readily available, it just needs to be used. Whether flushing is intended
or not will now be signalled by an explicit parameter rather than by
whether the packet parameter is NULL. This removes a few checks in
parse_packet(), gets rid of the initialization of the stack packet and
also reduces usage of sizeof(AVPacket) in libavformat.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, read_frame_internal in avformat/utils.c uses a spare
packet on the stack that serves no real purpose: At no point in this
function is there a need for another packet besides the packet destined
for output:
1. If the packet doesn't need a parser, but is output as is, the content
of the spare packet (that at this point contains a freshly read packet)
is simply copied into the output packet (via simple assignment, not
av_packet_move_ref, thereby confusing ownership).
2. If the packet needs parsing, the spare packet will be reset after
parsing and any packets resulting from the packet read will be put into
a packet list; the output packet is not used here at all.
3. If the stream should be discarded, the spare packet will be
unreferenced; the output packet is not used here at all either.
Therefore the spare packet and the copies can be removed in principle.
In practice, one more thing needs to be taken care of: If ff_read_packet
failed, the output packet was not affected, now it is. But given that
ff_read_packet returns a blank (as if reset via av_packet_unref) packet
on failure, there is no problem from this side either.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When AVFMT_FLAG_GENPTS is set, av_read_frame would put a reference to a
packet in the packet list (via av_packet_ref) and then immediately
thereafter unreference the original packet. This has been changed to
move the reference instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, avformat_find_stream_info had a potential for memleaks:
When everything was fine, it read packets and (depending upon whether
AVFMT_FLAG_NOBUFFER was set) put them in a packet list or unreferenced
them when they were no longer needed. But upon failure, said packets
would leak if they were not already on the packet list. This patch fixes
this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Since the recent changes to ff_packet_list_put, the source packet will
be automatically reset when the reference is moved to the packet list,
so that it is unnecessary to reinitialize the packet in the loops in
parse_packet and ff_read_packet; initializing once at the beginning is
enough.
This also fixes a potential, but currently unexisting problem: If the
raw packet buffer was initially not empty and probe_codec() failed,
then the packet returned would not be initialized. But given that
probe_codec() currently can't fail (always returns 0) this was not an
acute danger.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is done so that its data is really owned by the packet.
This was already true for the current callers.
Signed-off-by: James Almer <jamrial@gmail.com>
Up until now, ff_packet_list_put had a flaw: When it moved a packet to
the list (meaning, when it ought to move the reference to the packet
list instead of creating a new one via av_packet_ref), it did not reset
the original packet, confusing the ownership of the data in the packet.
This has been done because some callers of this function were not
compatible with resetting the packet.
This commit changes these callers and fixes this flaw. In order to
indicate that the ownership of the packet has moved to the packet list,
pointers to constant AVPackets are used whenever the target of the
pointer might already be owned by the packet list.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
ff_read_packet had potential memleaks:
1. If av_packet_make_refcounted fails, it means that the packet is not
refcounted, but it could nevertheless carry side data and therefore
needs to be unreferenced.
2. If putting a packet on a packet list fails, it wasn't unreferenced.
Furthermore, read_frame_internal leaked a packet's (side) data if a
context update was required and failed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
There is currently an ordinary check for this (which would lead to a
memleak), but given that no demuxer should ever return a packet with an
invalid stream_index it is more appropriate for this to be an assert.
FATE passes with this change.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Several subtitle demuxers set negative durations
Fixes: signed integer overflow: 9223372036854775807 - -1 cannot be represented in type 'long'
Fixes: 16925/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5766519790764032
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
1. Instead of relying on ff_packet_list_get to get the oldest element in
an AVPacketList, ff_read_packet used its own ad-hoc code. Said code
forgot to set the end of the list to NULL if the last element of the
list has been removed, thereby leaving the list in an inconsistent state.
2. Furthermore, if the list was not empty, the oldest element of the
list would always be copied into another packet structure before it was
known whether the oldest entry of the list would be removed. This makes
the ownership confusing and potentially copies unnecessarily.
Both of these issues have been fixed. ff_packet_list_get is used now.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avio_feof() returns true both in case of actual EOF and in case of IO errors.
Some demuxers (matroska) have special handling to be able to return the proper
error for this exact reason, e.g.:
if (avio_feof(pb)) {
if (pb->error) {
return pb->error;
} else {
return AVERROR_EOF;
}
}
However, most of the demuxers do not, and they simply return AVERROR_EOF if
avio_feof() is true, so there is a real chance that IO errors are mistaken for
EOF.
We might just say that the API user should always check the IO context error
attribute on EOF to make sure no IO errors happened, but not even ffmpeg.c does
this. It should be more intuitive to the API user if we simply return the IO
error as the return value of av_read_frame() instead of AVERROR_EOF.
Signed-off-by: Marton Balint <cus@passwd.hu>
fix error like "offset 0x1f85: partial file", the root cause is when
read the mp4 file from http, and the moov in the end of the mp4 file,
reconfig the buffer will drop some data.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Signed-off-by: Zhongxing Jiang <tomajsjiang@tencent.com>
Fixes: signed integer overflow: 9151595917793558550 + 297519050751678697 cannot be represented in type 'long'
Fixes: 15496/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5722866475073536
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: division by 0
Fixes: 15480/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5746727434321920
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reverts commit dd06f022b0.
Fixes ticket #7871 and reopens ticket #7816.
The introduced regression caused URL's with @ in them to be parsed incorrectly
which is a bigger issue then not being able to specify the slash character as a
password.
I think there are better ways to fix the original issue, like being able to
specify HTTP username and password as a protocol option, or adding a protocol
option to percent-decode the URL first.
Signed-off-by: Marton Balint <cus@passwd.hu>
This patch improves the logs when the message "cur_dts is invalid" appears.
If helps to identify which stream generates the trouble,
and the status of the stream.
A lot of users suffers with the message, and the origin varies.
The improved message can help to discover the cause.
Signed-off-by: Andreas Hakon <andreas.hakon@protonmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
After this change we always parse the full specifier even if we know the result
in the middle of the parsing. Sligtly slower, but this is needed to
consistently reject incorrect specifiers in both matching and non-matching
cases.
Signed-off-by: Marton Balint <cus@passwd.hu>
This reworks the code to be more strict about accepting stream specifiers. From
now on we strictly enforce the syntax in the documentation up until the
decisive part of the stream specifier. Therefore matching stream specifiers
always need to be correct, non matching specifiers only need to be correct
until the decisive part.
Also recursion is changed to a simple loop.
Signed-off-by: Marton Balint <cus@passwd.hu>
This removes lots of code duplication and also allows more complex specifiers,
for example you can use p:204:aⓂ️language:eng to select the English language
audio stream from program 204.
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes: signed integer overflow: 7738135736989908991 - -7954308516317364223 cannot be represented in type 'long'
Fixes: find_stream_info_usan
Reported-by: Thomas Guilbert <tguilbert@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This avoids surprising developers. Its bad to surprise developers with
such unexpected things.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We check for the documented explanation of the "Ignore code" in extract_extradata_check() already
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Because it will be used by avformat/segment.c or other module which
need to automatically create sub-directories operation.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
This utility function creates 64-bit NTP time format as per the RFC
5905.
A simple explaination of 64-bit NTP time format is here
http://www.beaglesoft.com/Manual/page53.htm
These fields will allow the mpegts demuxer to expose details about
the PMT/program which created the AVProgram and its AVStreams.
In mpegts, a PMT which advertises streams has a version number
which can be incremented at any time. When the version changes,
the pids which correspond to each of it's streams can also change.
Since ffmpeg creates a new AVStream per pid by default, an API user
needs the ability to (a) detect when the PMT changed, and (b) tell
which AVStream were added to replace earlier streams.
This has been a long-standing issue with ffmpeg's handling of mpegts
streams with PMT changes, and I found two related patches in the wild
that attempt to solve the same problem:
The first is in MythTV's ffmpeg fork, where they added a
void (*streams_changed)(void*); to AVFormatContext and call it from
their fork of the mpegts demuxer whenever the PMT changes.
The second was proposed by XBMC in
https://ffmpeg.org/pipermail/ffmpeg-devel/2012-December/135036.html,
where they created a new AVMEDIA_TYPE_DATA stream with id=0 and
attempted to send packets to it whenever the PMT changed.
Signed-off-by: Aman Gupta <aman@tmm1.net>
For seekable mpegts streams, duration is calculated from
pts by seeking to the end of the file for a pts and subtracting
the initial pts to compute a duration.
This can be expensive in terms of added latency during
probe, especially when streaming over a network. This new
option lets you skip the duration calculation, which is useful
when you don't care about the value and want to save some overhead.
This patch is particularly useful when dealing with live mpegts
streams. Normally such streams are not seekable, so durations
are not calculated. However in my case I am dealing with a seekable
live mpegts stream (networked access to a .ts file which is still
being appended to).
Signed-off-by: Aman Gupta <aman@tmm1.net>
Similar to 4c9c4fe8b2, but for durations. This fixes#7151, where
the report duration and bitrate on a mpegts stream is wildly off
due to the dvb_teletext stream's timings.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If the parser returns full frames, then the output pointer retured by
av_parser_parse2() is guaranteed to point to data contained in the
input packet's buffer.
Create a new reference to said buffer in that case, to avoid
unnecessary data copy when queueing the packet later in the function.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: runtime error: signed integer overflow: 18133149658382192 - -9223090561878065151 cannot be represented in type 'long long'
Fixes: crbug 831552
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: crbug 829153
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In some cases, mainly working with multiprogram mpeg-ts containers as
input, it would be handy to select sub stream of a specific program by
their metadata.
This patch makes it possible to narrow the stream selection among
streams of the specified program by stream metadata.
Examples:
p:601:m:language:hun will select all sub streams of program with id 601
where sub streams have metadata key named 'language' with value 'hun'.
p:602:m:guide will select all sub streams of program with id 602 where
sub streams have metadata key named 'guide'.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently when specifying the program id you can only decide to select
all stream of the specified program (e.g. p:103 will select all streams
of program 103) or narrow the selection to a specific stream sub index
(e.g. p:145:1 will select 2nd stream of program 145.) But you can not
specify like all audio streams of program 145 or 3rd video stream of
program 311.
In some case, mainly working with multiprogram mpeg-ts containers as
input, this feature would be handy.
This patch makes it possible to narrow the stream selection among
streams of the specified program by stream type and optionally its
index. Handled types: a, v, s, d.
Examples: p:601:a will select all audio streams of program 601,
p:603:a:1 will select 2nd audio streams of program 603,
p:604:v:0 will select first video stream of program 604.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: signed integer overflow: 7738135736989908991 - -7898362169240453118 cannot be represented in type 'long'
Fixes: Chromium bug 796778
Reported-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This prevents leaks in the rare cases the function is called when extradata
already exists.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This only affected demuxers that didn't return reference counted packets.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
This will replace the 1024 character limited filename field. Compatiblity for
output contexts are provided by copying filename field to URL if URL is unset
and by providing an internal function for muxers to set both url and filename
at once.
Signed-off-by: Marton Balint <cus@passwd.hu>
Enables getting access to ID3 PRIV tags from the command-line or metadata API
when demuxing. The PRIV owner is stored as the metadata key prepended with
"id3v2_priv.", and the data is stored as the metadata value. As PRIV tags may
contain arbitrary data, non-printable characters, including NULL bytes, are
escaped as \xXX.
Similarly, any metadata tags that begin with "id3v2_priv." are inserted as ID3
PRIV tags into the output (assuming the format supports ID3). \xXX sequences in
the value are un-escaped to their byte value.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
It was sort of optional before - if you didn't call it, networking was
initialized on demand, and an ugly warning was logged. Also, the doxygen
comments threatened that it would be made strictly required one day.
Make it explicitly optional. I would prefer to deprecate it fully, but
there might still be legitimate reasons to use this. But the average
user won't need it.
This is needed only for two reasons: to initialize TLS libraries like
OpenSSL and GnuTLS, and winsock.
OpenSSL and GnuTLS were already silently initialized on demand if the
global network init function was not called. They also have various
thread-safety acrobatics, which make concurrent initialization within
libavformat safe. In addition, the libraries are moving towards making
their global init functions safe, which removes all need for central
global init. In particular, GnuTLS 3.5.16 and OpenSSL 1.1.0g have been
found to have safe init functions. In all cases, they use internal
reference counters to avoid that the global uninit functions interfere
with concurrent uses of the library by other API users who called global
init.
winsock should be thread-safe as well, and maintains an internal
reference counter as well.
Since we still support ancient TLS libraries, which do not have this
fixed, and since it's unknown whether winsock and GnuTLS
reinitialization is costly in any way, don't deprecate the libavformat
functions yet.
It's completely absurd that libavcodec would care about libavformat
locking, but it was there because the lock manager was in libavcodec.
This is more stright forward. Changes ABI, but we don't require ABI
compatibility currently.
2LL << (wrap_bits=64 - 1) does not fit in int64_t; change the
code to use a uint64_t (2ULL) and add an av_assert2() to
ensure wrap_bits <= 64.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It has no reason to be in a public header, even if defined as private.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
