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>
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>
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>
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>
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>
This gets rid of this warning:
libavformat/rtsp.c: In function ‘rtsp_parse_transport’:
libavformat/rtsp.c:794: warning: cast discards qualifiers from pointer target type
Signed-off-by: Martin Storsjö <martin@martin.st>
This seems to be the correct mode to send, according to the
original RTSP RFC, and matches the method RECORD which is
sent later when starting to send data.
Darwin Streaming Server works fine with either of them.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some systems abuse the static payload types 35 or 36 (which
according to IANA are unassigned) for H264.
Signed-off-by: Martin Storsjö <martin@martin.st>
The strtol() interface makes it difficult to use with
const-qualified pointers. With this change, although
the const is still lost, the compiler does not warn
about it.
Signed-off-by: Mans Rullgard <mans@mansr.com>
This avoids exposing a dummy AVStream which won't get any data
and which will make avformat_find_stream_info wait for info about
this stream.
Signed-off-by: Martin Storsjö <martin@martin.st>
Make the muxers/demuxers that use the field handle the default
-1 in the same way as 0.
This allows distinguishing an intentionally set 0 from the default
value where the user hasn't set it.
Signed-off-by: Martin Storsjö <martin@martin.st>
This returns 200 OK for OPTIONS requests and 501 Not Implemented
for all other requests.
Even though this doesn't do much actual handling of the requests,
it makes the code properly identify server requests as such, instead
of interpreting it as a reply to the client's request as it did
before.
Signed-off-by: Martin Storsjö <martin@martin.st>
The rtp demuxer which listens for RTP packets and detects the
RTP payload type will currently get confused if the first packet
received is an RTCP packet. Thus ignore such packets.
Signed-off-by: Martin Storsjö <martin@martin.st>
Martin Storsjö
Luca Barbato
Diego Biurrun
Michael Niedermayer
Jordi Ortiz
Anton Khirnov
Ronald S. Bultje
Mans Rullgard
Tommy Winther