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>
(cherry picked from commit 1338dc0823)
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>
(cherry picked from commit ce41c51b0c)
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>
(cherry picked from commit d9c0510e22)
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>
This also lists the objects from those two libraries as internal (by adding
the ff_ prefix) so that they can then be hidden via linker scripts.
(cherry picked from commit c6610a216e)
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
This may be needed to avoid calls to implicitly defined functions
(that will be removed by dead code elimination later anyway).
Originally committed as revision 25585 to svn://svn.ffmpeg.org/ffmpeg/trunk
Martin Storsjö
Luca Barbato
Diego Elio Pettenò
Aurelien Jacobs