Mixing these with the rtp depacketizer functions in rtpdec.h is
no good.
Signed-off-by: Martin Storsjö <martin@martin.st>

This fixes connecting to "Ceton InfiniTV4 PCIe & USB".
Signed-off-by: Martin Storsjö <martin@martin.st>

Fixes Ticket2314
Fixes connecting to "Ceton InfiniTV4 PCIe & USB"
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This gets rid of a number of special cases from the common rtpdec
code.
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 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>

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 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>

This allows calling other dynamic payload handler functions if
needed.
Signed-off-by: Martin Storsjö <martin@martin.st>

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>

Signed-off-by: Martin Storsjö <martin@martin.st>

This allows depacketizers to figure out if packets have been lost.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

The previous comment about the buffer was wildly inaccurate and
misleading.
Signed-off-by: Martin Storsjö <martin@martin.st>

These stem from back when both the rtp muxer and rtp depacketizing
shared the same struct.
Signed-off-by: Martin Storsjö <martin@martin.st>

Anonymous structs cannot be forward declared and have no benefit.

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

The timestamp field in RTPDemuxContext was unused before this.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

This avoids clashes if we internally want to override the global
open function.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit 119cc033)

Signed-off-by: Mans Rullgard <mans@mansr.com>

Emitted timestamps in each stream start from 0, for the first received
RTP packet. Once an RTCP packet is received, that one is used for
sync, emitting timestamps that fit seamlessly into the earlier ones.

Originally committed as revision 26187 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 25891 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 25890 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 25556 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 25555 to svn://svn.ffmpeg.org/ffmpeg/trunk

Reordering is enabled only when receiving over UDP.

Originally committed as revision 25294 to svn://svn.ffmpeg.org/ffmpeg/trunk

Do the same change for ff_rdt_parse_packet, too, to keep the interfaces
similar.

Originally committed as revision 25289 to svn://svn.ffmpeg.org/ffmpeg/trunk

Patch by Josh Allmann, joshua dot allmann at gmail

Originally committed as revision 24929 to svn://svn.ffmpeg.org/ffmpeg/trunk

It will be used by other parts of lavf now. This reverts svn rev 23846.

Originally committed as revision 24265 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 24234 to svn://svn.ffmpeg.org/ffmpeg/trunk