In ff_rtp_get_payload_type, the AVFormatContext is used for checking
whether the payload_type or rtpflags options are set. In rtpenc_chain,
the rtpctx struct is a newly initialized struct where no options have
been set yet, so no options can be fetched from there.
All muxers that internally chain rtp muxers have the "rtpflags" field
that allows passing such options on (which is how this worked before
8034130e06), so this works just as intended.
This makes it possible to produce H263 in RFC2190 format with chained
RTP muxers.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
Not sure if this actually happens, but we do the same check when
checking payload_type further above in the function, so it might
be needed.
Signed-off-by: Martin Storsjö <martin@martin.st>
The check `start + res < start' is broken since pointer overflow is
undefined behavior in C. Many compilers such as gcc/clang optimize
away this check.
Use `res > end - start' instead. Also change `res' to unsigned int
to avoid signed left-shift overflow.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
A negative `size' will bypass FFMIN(). In the subsequent memcpy() call,
`size' will be considered as a large positive value, leading to a buffer
overflow.
Change the type of `size' to unsigned int to avoid buffer overflow, and
simplify overflow checks accordingly. Also change a literal buffer
size to use sizeof, and limit the amount of data copied in another
memcpy call as well.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Sanity checks like `data + size >= data_end || data + size < data' are
broken, because `data + size < data' assumes pointer overflow, which is
undefined behavior in C. Many compilers such as gcc/clang optimize such
checks away.
Use `size < 0 || size >= data_end - data' instead.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Expose the current sequence number via an AVOption - this can
be used both for setting the initial sequence number, or for
querying the current number.
Signed-off-by: Martin Storsjö <martin@martin.st>
Use AVERROR_INVALIDDATA on invalid inputs, and AVERROR_EOF when no more
frames are available in an interleaved AVI.
Signed-off-by: Jindrich Makovicka <makovick@gmail.com>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
The theoretical minimum for a (not totally well formed) RTCP packet
is 8 bytes, so we shouldn't require 12 bytes as minimum input.
Also return AVERROR_INVALIDDATA instead of 0 if something that is
not a proper packet is given.
Signed-off-by: Martin Storsjö <martin@martin.st>
This clarifies where the limit number comes from, and only
requires exactly as much padding space as will be needed.
Signed-off-by: Martin Storsjö <martin@martin.st>
The main difference to the existing suites from RFC 4568 is
that the version with a 32 bit HMAC still uses 80 bit HMAC
for RTCP packets.
Signed-off-by: Martin Storsjö <martin@martin.st>
The lavf-internal parser functions are used when receiving
mpegts over RTP. This fixes memory leaks in this setup.
The normal mpegts demuxer close function was updated in ec7d0d2e in
2004 to fix leaks, but the parsing function used for RTP wasn't
updated and has been leaking ever since.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes the returned data valid to stream copy into other
containers as well, not only for decoding straight away.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is mostly useful for encryption together with the RTP muxer,
but could also be set up as IO towards the peer with the SDP
demuxer with custom IO.
Signed-off-by: Martin Storsjö <martin@martin.st>
This only takes care of decrypting incoming packets; the outgoing
RTCP packets are not encrypted. This is enough for some use cases,
and signalling crypto keys for use with outgoing RTCP packets
doesn't fit as simply into the API. If the SDP demuxer is hooked
up with custom IO, the return packets can be encrypted e.g. via the
SRTP protocol.
If the SRTP keys aren't available within the SDP, the decryption
can be handled externally as well (when using custom IO).
Signed-off-by: Martin Storsjö <martin@martin.st>
This supports the AES_CM_128_HMAC_SHA1_80 and
AES_CM_128_HMAC_SHA1_32 cipher suites (from RFC 4568) at the
moment. The main missing features are replay protection (which can be
added later without changing the internal API), and the F8 and null
ciphers.
Signed-off-by: Martin Storsjö <martin@martin.st>
The function is a callback that is called by ff_gen_search with
a constant stream index.
Avoid a false positive on older gcc version.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This makes the behaviour defined when they wrap around. The value
assigned to expected_prior was a uint32_t already.
Signed-off-by: Martin Storsjö <martin@martin.st>
Without this, we'd signal a huge loss rate (due to unsigned
wraparound) if we had received one packet more than expected (that
is, one seq number sent twice). The code has a check for lost_interval
<= 0, but that doesn't do what was intended as long as the variable is
unsigned.
Signed-off-by: Martin Storsjö <martin@martin.st>
The code below the comment does not at all relate to statistics,
and even if moved to the right place, the comment adds little
value.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously, we always signalled a zero time since the last RTCP
SR, which is dubious.
The code also suggested that this would be the difference in
RTP NTP time units (32.32 fixed point), while it actually is
in in 1/65536 second units. (RFC 3550 section 6.4.1)
Signed-off-by: Martin Storsjö <martin@martin.st>
This brings back some code that was added originally in 4a6cc061
but never was used, and was removed as unused in 4cc843fa. The
code is updated to actually work and is tested to return sane
values.
Signed-off-by: Martin Storsjö <martin@martin.st>
The base_seq variable is set to first_seq - 1 (in
rtp_init_sequence), so no + 1 is needed here.
This avoids reporting 1 lost packet from the start.
Signed-off-by: Martin Storsjö <martin@martin.st>
The question can be answered: No, we do not know the initial sequence
number from the SDP. In certain cases, it can be known from the
RTP-Info response header in RTSP though. (In that case, we use it as
timestamp origin, but not for rtp receiver statistics.)
Signed-off-by: Martin Storsjö <martin@martin.st>
It is unclear what the bug exactly was and if it ever was fixed,
and we don't even support decoding via faad any longer. The
comment has been present since d0deedcb in 2006.
Signed-off-by: Martin Storsjö <martin@martin.st>
One of them is renamed now, but mentioning it by name serves
no purpose here. The other table mentioned ceased to exist
under that name in 4934884a1 in 2006.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously, for broken frames, we only returned the first partition
of the frame (we would append all the received packets to the packet
buffer, then set pkt->size to the size of the first partition, since
the rest of the frame could have lost data inbetween) - now instead
return the full buffered data we have, but don't append anything more
to the buffer after the lost packet discontinuity. Decoding the
truncated packet should hopefully get better quality than trimming out
everything after the first partition.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is required by RFC 3550 (section 6.5):
The list of items in each chunk MUST be terminated by one or more
null octets, the first of which is interpreted as an item type of
zero to denote the end of the list.
This was implicitly added as padding before, unless the host name
length matched up so no padding was added.
This makes wireshark parse the packets properly if other RTCP items
are appended to the same packet.
Signed-off-by: Martin Storsjö <martin@martin.st>
Add some additional checks for EOF and print error messages on an incomplete
header or packet.
FATE reference updated for id-cin-video due to the demuxer no longer
returning a partial video packet at EOF.
This allows the caller to either include them (and get more packets
decoded, but possibly some nonperfect frames), or discard them (by
setting fflags=discardcorrupt).
Signed-off-by: Martin Storsjö <martin@martin.st>
This uses page duration instead of byte size to determine when to buffer
the page. Also, it tries to avoid continued pages by buffering the current
page if there are already packets in the page and adding the next packet
would require it to be continued on a new page. This can improve seeking
performance.
The default page duration is 1 second, which is much saner than filling
all page segments by default.
This sends NACK for missed packets and PLI (picture loss indication)
if a depacketizer indicates that it needs a new keyframe, according
to RFC 4585.
This is only enabled if the SDP indicated that feedback is supported
(via the AVPF or SAVPF profile names).
The feedback packets are throttled to a certain maximum interval
(currently 250 ms) to make sure the feedback packets don't eat up
too much bandwidth (which might be counterproductive). The RFC
specifies a more elaborate feedback packet scheduling.
The feedback packets are currently sent independently from normal
RTCP RR packets, which is not totally spec compliant, but works
fine in the environments I've tested it in. (RFC 5506 allows this,
but requires a SDP attribute for enabling it.)
Signed-off-by: Martin Storsjö <martin@martin.st>
The warning is a false positive, but I prefer actually initializing
it over masking it with av_uninit, since the code is not performance
critical.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is a bug from c7d4de3d73 - if the previous frame wasn't
returned yet (due to missing the final packets), but we have
enough data of it to return the first partition, we write that into
pkt and set returned_old_frame. That commit forgot returning 0 for
the case where this current packet didn't have the end_packet flag
set.
Signed-off-by: Martin Storsjö <martin@martin.st>
If we timed out and consumed a packet from the reordering queue,
but didn't return a packet to the caller, recheck the queue status.
Otherwise, we could end up in an infinite loop, trying to consume
a queued packet that has already been consumed.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
The following out-of-memory check is broken.
*sorted_segments = av_mallocz(...);
if (!sorted_segments) { ... }
The correct NULL check should use *sorted_segments.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
To use this, set sdpflags=custom_io to the sdp demuxer. During
the avformat_open_input call, the SDP is read from the AVFormatContext
AVIOContext (ctx->pb) - after the avformat_open_input call,
during the av_read_frame() calls, the same ctx->pb is used for reading
packets (and sending back RTCP RR packets).
Normally, one would use this with a read-only AVIOContext for the
SDP during the avformat_open_input call, then close that one and
replace it with a read-write one for the packets after the
avformat_open_input call has returned.
This allows using the RTP depacketizers as "pure" demuxers, without
having them tied to the libavformat network IO.
Signed-off-by: Martin Storsjö <martin@martin.st>
So far, aviocontexts are used either in pure-read or pure-write
mode - full read/write mode doesn't work well (and implementing it
is a much larger, not totally trivial change).
This patch allows using avio_read and ffio_read_partial on
read/write aviocontexts, where the read operations are passed
through directly unbuffered, while writes are buffered as usual.
This is enough to support the operations needed by packet based
data transfer like in udp/rtp, where aviocontext is the only
public API for hooking up custom IO.
Signed-off-by: Martin Storsjö <martin@martin.st>
The function find_things() in configure is confused by component
registration calls as part of multiline macros defining combined
component registration. Coalesce those macros into one line to
work around the issue.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Signed-off-by: Martin Storsjö <martin@martin.st>
Limelight is a not too uncommon CDN. The authentication scheme is
pretty similar to the adobe authentication, but is even closer to
normal http digest authentication (but not close enough to warrant
sharing code) than the adobe version.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is mostly used to authenticate the client when publishing.
Tested with wowza and akamai.
Some but not all servers support resending a new connect invoke
within the same connection, so always reconnect for sending a new
connection attempt. This matches what other applications do as well.
The authentication scheme is structurally pretty similar to http
digest authentication, but uses base64 instead of hex strings.
Signed-off-by: Martin Storsjö <martin@martin.st>
Also fixes linking in various configs with only individual parts enabled
because the RTP muxer chaining code depends on the general RTP code,
which is now accounted for.
If s->filename doesn't contain any period/filename extension to strip
away, the buffer will be too small to fit both strings. This isn't
any buffer overflow since the concatenation uses av_strlcat with
the right buffer size.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is built on the assumption that the first partition of each
VP8 packet is essential for decoding any later packet - if this
partition is broken/missed, the arithmetic coder gets out of sync
and decoding the bitstream in further packet ends up with total
garbage. If packets of a frame are lost, make sure the first
partition is intact (return only this part of the packet, nothing
else), otherwise stop returning data until the next keyframe is
received.
Alternatively, one would simply not return any packets at all
until the next keyframe, if packet loss is detected.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes all users of rtpenc_chain (rtsp muxer, sapenc, mov
rtp hinting) work again, broken since 8034130e0.
Signed-off-by: Martin Storsjö <martin@martin.st>
The FLV muxer tries to update the header in write_trailer, which is
impossible if writing to a pipe or network stream. Don't write header
data if seeking to the header fails.
Signed-off-by: Martin Storsjö <martin@martin.st>
The sample in https://bugzilla.libav.org/show_bug.cgi?id=393 and
samples/F4V/H263_NM_f.mp4 both have codec_tag H263 for different
codecs. H263 is apparently used by Flash Media Server for Sorensen
Spark videos.
Patch based on commit 5442083b1c by
Carl Eugen Hoyos. Fixes bug 393.
This makes it easier for receivers to decide what to do if data
is lost.
Refactor calculating the max payload size, to avoid hardcoding the
header size in too many places, reducing the number of lines that
have to be touched if the header is adjusted further.
Signed-off-by: Martin Storsjö <martin@martin.st>
Avoids trying to read a packet with 0 or negative size.
Avoids a potential infinite loop due to seeking backwards.
Partially based on a patch by Michael Niedermayer.
This comment was added in e309128f, in 2002, and has been brought
along since then more or less unmodified.
The first point of the todo was implemented in dbf30963 in 2006,
the second one is not relevant to rtpdec.c (brought along from
rtp.c in 8eb793c4 in 2008) but would be more relevant to the
rtp muxer, although it isn't a good idea anyway.
Signed-off-by: Martin Storsjö <martin@martin.st>
