According to the RFC, GET_PARAMETER should be used for
this, and according to a report from Tim Ouellette,
OPTIONS doesn't work for keeping the connection alive for some
servers. Also, live555 uses GET_PARAMETER for this purpose.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This allows libavformat to guess an estimated duration for
amr files.
For streams with varying bit rates (or with silence descriptors
or "no frame" blocks) the guess is, of course, inaccurate.
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>
A similar variable for the total stream duration was changed to
int64_t in b79c3df088, due to overflows in some odd
streams.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This fixes crashes on exit when plaing some RealRTSP streams
(among other), e.g.
rtsp://dl.lib.brown.edu:554/areserves/1093545294660883.mp3.
These crashes have been present since 3e68b3ba7b.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Add an APIchanges entry for the av_pkt_dump2 and av_pkt_dump_log2
functions, and a changelog entry for the apple http live streaming
protocol handler.
Since neither of them got a minor bump at commit time, but were
applied before the jv demuxer, they all can be considered added
in this minor version.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
If this flag is set, the protocol can handle URLs where the
scheme is a nested scheme such as applehttp+file: - the protocol
can handle any URL where the first segment of the nested scheme
belongs to this protocol.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
In most cases, s->buf_ptr will be equal to s->buf_end when
fill_buffer is called, but this may not always be the case, if
we're seeking forward by reading (permitted by the short seek
threshold).
If fill_buffer is writing to s->buf_ptr instead of s->buf_end (when
they aren't equal and s->buf_ptr is ahead of s->buffer), the data
between s->buf_ptr and s->buf_end is overwritten, leading to
inconsistent buffer content. This could return incorrect data if
later seeking back into the area before the current s->buf_ptr.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
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>
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>
If required, the caller can do this itself. ff_write_chained rescales
timestamps as necessary, and all current callers of rtpenc_chain
use ff_write_chained, making this timebase copy unnecessary.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This function is useful for freeing data structures allocated by
muxers, which currently have to be freed manually by the caller.
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>
The key string is supposed to contain the equals character,
too. Since the checked string was wrong, and the return value
check was wrong too, it incorrectly seemed to work right before.
Signed-off-by: Mans Rullgard <mans@mansr.com>
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
If the remote address is updated later with this function, the caller
shouldn't set the connect option until in this call.
Originally committed as revision 26245 to svn://svn.ffmpeg.org/ffmpeg/trunk
By calling connect on the UDP socket, only packets from the chosen
peer address and port are received on the socket. This is one
solution to issue 1688.
Originally committed as revision 26244 to svn://svn.ffmpeg.org/ffmpeg/trunk
For MS-RTSP, we don't always get RTCP packets (never?), so the earlier
timestamping code never wrote anything into pkt->pts. The rtpdec_asf
depacketizer just sets the dts of the packet, so if the generic RTP
timestamping is used, too, we get inconsistent timestamps.
Therefore, skip the generic RTP timestamp algorithm if the depacketizer
already has set something.
This fixes "Invalid timestamps" warnings, present since SVN rev 26187.
Originally committed as revision 26241 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 fixes compilation with --disable-everything --enable-<component>,
for all encoders, decoders, muxers, demuxers, parsers, protocols, bsfs,
indevs, outdevs and filters at the moment. (All those that work without
any external dependencies at least.)
Originally committed as revision 26076 to svn://svn.ffmpeg.org/ffmpeg/trunk
This fixes building with --disable-everything --enable-muxer=matroska and/or
--enable-muxer=webm
Originally committed as revision 26067 to svn://svn.ffmpeg.org/ffmpeg/trunk
This fixes one of the issues found if building with
--disable-everything --enable-muxer=webm
Originally committed as revision 26066 to svn://svn.ffmpeg.org/ffmpeg/trunk
Since SVN rev 25866, this table is used by the trellis encoder, too,
not only by the decoder.
Originally committed as revision 26065 to svn://svn.ffmpeg.org/ffmpeg/trunk
While not mentioned in RFC 4629, this is required for H.263 in
3GPP TS 26.234. It is in practice required for playback with
Android stagefright and on Samsung bada phones.
Originally committed as revision 26062 to svn://svn.ffmpeg.org/ffmpeg/trunk
This macro is disabled if --enable-small or --disable-optimizations are set.
Currently, this leads to warnings about functions being defined but not used,
for functions in header files.
By defining av_always_inline as inline or as av_unused, we avoid these
warnings.
This doesn't make a normal build with --enable-small any larger,
since the compiler probably chooses not to inline these functions even
if they're marked as inline.
Originally committed as revision 26032 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
This fixes playback of a RealRTSP/MP3 URL from the RTSP samples on
MultimediaWiki.
Originally committed as revision 25906 to svn://svn.ffmpeg.org/ffmpeg/trunk
According to the spec, this type shouldn't ever be used. Nevertheless,
passing it through enables decoding streams which otherwise aren't
decodeable.
Originally committed as revision 25897 to svn://svn.ffmpeg.org/ffmpeg/trunk
The current implementation is incompatible with the latest spec drafts,
this should be communicated clearly to the user.
Originally committed as revision 25887 to svn://svn.ffmpeg.org/ffmpeg/trunk
Wraparound in ssd is mainly avoided by subtracting the ssd of the
best node from all the others once it has grown large enough.
If using very large trellis sizes (e.g. -trellis 15), the frontier
is so large that the difference between the best and the worst is
large enough to cause wraparound, even if the ssd of the best one
is subtracted regularly.
When using -trellis 10 on a 30 second sample, this causes only a slight
slowdown, from 61 to 64 seconds.
Originally committed as revision 25858 to svn://svn.ffmpeg.org/ffmpeg/trunk
This makes the wording consistent with how people usually talk about heaps.
Originally committed as revision 25775 to svn://svn.ffmpeg.org/ffmpeg/trunk
This increases the PSNR slightly (about 0.1 dB) for trellis sizes
below 8, and gives equal PSNR for sizes above that.
Originally committed as revision 25769 to svn://svn.ffmpeg.org/ffmpeg/trunk
This lowers the run time from 158 to 21 seconds, for -trellis 8
with a 30 second sample on my machine.
This requires 64 KB additional memory.
Originally committed as revision 25768 to svn://svn.ffmpeg.org/ffmpeg/trunk
By not looking for the exactly largest node, we avoid an O(n) seek through
the leaf nodes. Just pick one (not the same one every time) and try replacing
that node with the new one.
For -trellis 8, this lowers the run time from 190 to 158 seconds,
for a 30 second 44 kHz mono sample, on my machine.
Originally committed as revision 25733 to svn://svn.ffmpeg.org/ffmpeg/trunk
This avoids having to memmove the large parts of the array when inserting into
it.
For -trellis 8, this lowers the run time from 245 seconds to 190 seconds,
for a 30 second 44 kHz mono sample, on my machine.
Originally committed as revision 25731 to svn://svn.ffmpeg.org/ffmpeg/trunk
handle_jpeg may update the src/dstFormat variables, this makes sure the
updated version is stored in the context.
This fixes roundup issue 2302.
Patch by Troot, all_crap_goes_here at hotmail
Originally committed as revision 32562 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
Martin Storsjö
