* commit '2f3bada63e57345329c4f9b48e9b81b5cfc03d05':
lavf: Add a protocol for SRTP encryption/decryption
rtsp: Support decryption of SRTP signalled via RFC 4568 (SDES)
Conflicts:
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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 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>
* commit 'e96406eda4f143f101bd44372f7b2d542183000a':
rtsp: Add support for depacketizing RTP data via custom IO
Conflicts:
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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>
The data does not contain timing or trailing line breaks anymore. In
addition to being less idiotic, it is consistent with other codecs and
thus allows more switches between formats and codecs. It also fixes the
issue of the trailing line returns being simple \n instead of CRLF in
the ASS rectangle dialogue (this is the reason of the FATE update).
* qatar/master:
rtmp: Add support for limelight authentication
rtmp: Add support for adobe authentication
Conflicts:
Changelog
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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>
Current MicroDVD AVPackets contain timing information and trailing line
breaks. The data is now only composed of the markup data. Doing this
consistently between text subtitles decoders allows to use different
codec for various formats. For instance, MicroDVD markup is sometimes
found in some VPlayer files. Also, generally speaking, the subtitles
text decoders have no use of these timings (and they must not use them
since it would break any user timing adjustment).
Technically, this is a major ABI break. In practice, a mismatching
lavf/lavc will now error out for MicroDVD decoding. Supporting both
formats requires unnecessary complex and fragile code.
FATE needs update because line breaks in the ASS file were "\n" (because
that's what is used in the original file). ASS format expect "\r\n" line
breaks; this commit fixes this issue. Also note that this "\r\n"
trailing need to be moved at some point from the decoders to the ASS
muxer.
Note that the linebreaks text codec option (but not the feature) has
been removed; its main goal was to allow demuxers to configure the text
decoder (and not meant to be used by users), but the AVOption are not a
viable solution. This is solved differently in this commit.
The new options reset the timestamps at each new segment, so that the
generated segments will have timestamps starting close to 0.
It is meant to address trac ticket #1425.
Gif demuxer is capable of extracting multiple frames from gif file.
In conjunction with gif decoder it implements support for reading
animated gifs.
Demuxer has two options available to user: default_delay and min_delay.
These options are for protection from too rapid gif animations. In practice
it is standard approach to slow down rendering of this kind of gifs. If you try to
play gif with delay between frames of one hundredth of second (100fps) using
one of major web browsers, you get significantly slower playback,
around 10 fps. This is because browser detects that delay value is less than some
threshold (usually 2 hundredths of second) and reset it to default value (usually 10
hundredths of second, which corresponds to 10fps). Manipulating these options user
can achieve the same effect during conversion to some video format. Otherwise user
can set them to not protect from rapid animations at all.
The other case when these options necessary is for gif images encoded according to
gif87a standard since prior to gif89a there was no delay information included in file.
Bump lavf minor version.
Signed-off-by: Vitaliy E Sugrobov <vsugrob@hotmail.com>
