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>
This avoids (for all practical cases) the issue of reusing
the same UDP port as for an earlier connection. If the remote
doesn't know the previous session was closed, he might keep
on sending packets to that port. If we always start off trying
to open the same UDP port, we might get those packets intermixed
with the new ones.
This is occasionally an issue when testing RTSP stuff with
DSS, perhaps also with other servers.
Signed-off-by: Martin Storsjö <martin@martin.st>
This check isn't relevant in the way the code currently works.
Also change a case of if (x == 0) into if (!x).
Signed-off-by: Martin Storsjö <martin@martin.st>
The media_type_mask is initialized via AVOptions for the
rtsp and sdp demuxers, but it isn't available as an option
for the rtp guessing demuxer (since it doesn't really make
sense there). Therefore, it must be manually initialized
instead, since a zero value means no media types at all
are accepted.
Signed-off-by: Martin Storsjö <martin@martin.st>
The chunksize internal variable has two different uses - for
reading, it's the amount of data left of the current chunk
(or -1 if the server doesn't send data in chunked mode), where
it's only an internal state variable. For writing, it's used
to decide whether to enable chunked encoding (by default), by
using the value 0, or disable chunked encoding (value -1).
This, while consistent, doesn't make much sense to expose
as an AVOption. This splits the usage of the internal variable
into two variables, chunksize which is used for reading (as
before), and chunked_post which is the user-settable option,
with the values 0 and 1, where 1 is default.
Signed-off-by: Martin Storsjö <martin@martin.st>
All current usages of it are incompatible with localization.
For example strcasecmp("i", "I") != 0 is possible, but would
break many of the places where it is used.
Instead use our own implementations that always treat the data
as ASCII.
Signed-off-by: Martin Storsjö <martin@martin.st>
Streams from RTSP or SDP that do not match an allowed type will
be skipped entirely, which allows video-only or audio-only
streaming from servers that provide both.
Signed-off-by: Martin Storsjö <martin@martin.st>
Manual replacements are done in this commit.
In many cases, the id is some constant made up number (e.g. 0 for video
and 1 for audio), which is then not used in the demuxer for anything.
Those ids are removed.
This allows setting the filter_src option for these demuxers, too,
which wasn't possible at all before (where the option only was set
via URL parameters for RTSP).
Signed-off-by: Martin Storsjö <martin@martin.st>
Eventually, the old way of passing options by adding
stuff to the URL can be dropped.
This avoids having to tamper with the user-specified URL to
pass options on the transport mode. This also works better
with redirects, since the options don't need to be parsed out
from the URL.
Signed-off-by: Martin Storsjö <martin@martin.st>
Use defines for shortening common parts, omit the .dbl named
initializer (since it's the first element in the union).
Signed-off-by: Martin Storsjö <martin@martin.st>
This eases adding options that are common for both. The
AV_OPT_FLAG_EN/DECODING_PARAM still indicates whether they belong
to the muxer or demuxer.
Signed-off-by: Martin Storsjö <martin@martin.st>
DSS enables this automatically if streaming VOD over TCP. If
enabled, the server feeds packets faster than realtime, screwing
up RTCP NTP based timestamps.
Also, DSS doesn't indicate that this was indicated, if it was
enabled automatically (although if it was requested to be enabled,
a header saying that it was enabled is added, but this isn't
added if it is enabled automatically), making it even harder
to detect and work around properly without explicitly asking
for it to be disabled(/enabled, if we were able to support it).
Signed-off-by: Martin Storsjö <martin@martin.st>
In this case, the string that was passed couldn't contain
user-defined data and thus there was no risk for injection
bugs, but it's safer this way, if we later change the
content of the options string.
Signed-off-by: Martin Storsjö <martin@martin.st>
strtol could return negative values, leading to various error messages,
mainly "non-monotonically increasing dts".
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This is more like what VLC does. If the server doesn't mention
supporting GET_PARAMETER in response to an OPTIONS request,
VLC doesn't send any keepalive requests at all. After this patch,
libavformat will still send OPTIONS keepalives if GET_PARAMETER
isn't explicitly said to be supported.
Some RTSP cameras don't support GET_PARAMETER, and will
close the connection if this is sent as keepalive request
(but support OPTIONS just fine, but probably don't need any
keepalive at all). Some other cameras don't support using
OPTIONS as keepalive, but require GET_PARAMETER instead.
Signed-off-by: Martin Storsjö <martin@martin.st>
Make AVIO_FLAG_ access constants work as flags, and in particular fix
the behavior of functions (such as avio_check()) which expect them to
be flags rather than modes.
This breaks API.
According to the RFC, the default is multicast if nothing is
specified, which doesn't make sense for TCP.
According to a bug report, some Axis camera models give a
"400 Bad Request" error if this is omitted.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Functions interrupted by url_interrupt_cb should not be restarted.
Therefore using AVERROR(EINTR) was wrong, as it did not allow to distinguish
when the underlying system call was interrupted and actually needed to be
restarted.
This fixes roundup issues 2657 and 2659 (ffplay not exiting for streamed
content).
Signed-off-by: Nicolas George <nicolas.george@normalesup.org>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Map EAGAIN and EINTR from ff_neterrno to the normal AVERROR()
error codes. Provide fallback definitions of other errno.h network
errors, mapping them to the corresponding winsock errors.
This eases catching these error codes in common code, without having
to distinguish between FF_NETERRNO(EAGAIN) and AVERROR(EAGAIN).
This fixes roundup issue 2614, unbreaking blocking network IO on
windows.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
In the name of consistency:
get_byte -> avio_r8
get_<type> -> avio_r<type>
get_buffer -> avio_read
get_partial_buffer will be made private later
get_strz is left out becase I want to change it later to return
something useful.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
init_put_byte should never be used outside of lavf, since
sizeof(AVIOContext) isn't part of public ABI.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
If udp_read_packet returns 0, rtsp_st isn't set and we shouldn't
treat it as a successfully received packet (which is counted and
possibly triggers a RTCP receiver report).
This fixes issue 2612.
This is used for mapping AVStreams back to their corresponding
RTSPStream. Since d9c0510, the RTSPStream pointer isn't stored in
AVStream->priv_data any longer, breaking this mapping from AVStreams
to RTSPStreams.
Also, we don't need to clear the priv_data in rdt cleanup any longer,
since it isn't set to duplicate pointers.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This avoids having the chained AVStream->codec point to the same
AVCodecContext owned by the outer AVStream. The downside is that
changes to the AVCodecContext made after calling av_write_header
cannot be detected automatically within the chained muxer.
This avoids having to manually unlink the chained AVStream->codec
by setting it to null before freeing the chained muxer via generic
freeing functions.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This fixes memory leaks in the RTSP muxer and RTP hinting in the
mov muxer present since SVN rev 25418.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
For mpegts in RTP, there isn't a direct mapping between RTSPStreams
and AVStreams, and the RTSPStream isn't ever stored in
AVStream->priv_data, which was earlier leaked. The fix for this
leak, in ea7f080749, lead to
double frees for other, normal RTP streams.
This patch avoids storing RTSPStreams in AVStream->priv_data, thus
avoiding the double free. The RTSPStreams are always available via
RTSPState->rtsp_streams anyway.
Tested with MS-RTSP, RealRTSP, DSS and mpegts/RTP.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
If filtered, only packets from the right source address and port
are received.
To test, play back e.g. some mpeg4 video RTSP stream (where the
video stream is the first stream in the presentation) over UDP.
While receiving this stream, send another stream to the same port:
ffmpeg -re -i <whatever> -vcodec mpeg4 -an -f rtp
rtp://127.0.0.1:5000?localport=1234
Normally, the RTSP playback reports lots of errors at this point.
If the RTSP stream has the ?filter_src option enabled, these
interferring packets are ignored.
Originally committed as revision 26246 to svn://svn.ffmpeg.org/ffmpeg/trunk
This avoids having a large temporary buffer in the struct used for
storing the rtsp reply headers.
Originally committed as revision 26192 to svn://svn.ffmpeg.org/ffmpeg/trunk
This allows ff_rtsp_parse_line to do more changes directly in RTSPState
when parsing the reply, instead of having to store large amounts of
temporary data in RTSPMessageHeader.
Originally committed as revision 26190 to svn://svn.ffmpeg.org/ffmpeg/trunk
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
For example MS-RTSP doesn't have RTPDemuxContexts for all streams.
This fixes issue 2448.
Originally committed as revision 26107 to svn://svn.ffmpeg.org/ffmpeg/trunk
This fixes a crash if we requested TCP interleaved transport, but the
server replies with transport data for UDP. According to the RFC, the
server isn't allowed to respond with another transport type than the
one requested.
Originally committed as revision 26077 to svn://svn.ffmpeg.org/ffmpeg/trunk
This also reverts SVN rev 26016, which incorrectly overwrote the time base
with 90 kHz for all streams, regardless of what was set by the SDP parsing.
The stream that triggered the fix in 26016 still works after this commit.
Originally committed as revision 26022 to svn://svn.ffmpeg.org/ffmpeg/trunk
This fixes cases where the RTP time base and the sample rate of the stream
differ. Previously, the AVStream time_base was unconditionally set to
the sample rate (which initially was set to one value when parsing the
rtpmap field in the SDP, but later overridden by an a=SampleRate field).
Additionally, this makes the code actually use the stream time base set
in rtpmap for video codecs, instead of hardcoding it to always be 90 kHz.
Originally committed as revision 25908 to svn://svn.ffmpeg.org/ffmpeg/trunk
