If these aren't reset, the timestamps make a huge jump when the next RTCP
is received.
Originally committed as revision 22918 to svn://svn.ffmpeg.org/ffmpeg/trunk
In order to sync RTP streams that get their initial RTCP timestamp at
different times, propagate the NTP timestamp of the first RTCP packet
to all other streams.
This makes the timestamps of returned packets start at (near) zero instead
of at any random offset.
Originally committed as revision 22917 to svn://svn.ffmpeg.org/ffmpeg/trunk
but doesn't actually do that. What's worse, it creates timestamp adjustments
that are different per stream within a session, leading to a/v sync issues.
See discussion in thread "[FFmpeg-devel] rtp streaming x264+audio issues (and
some ideas to fix them)". Patch suggested by Luca Abeni <lucabe72 email it>.
Originally committed as revision 21857 to svn://svn.ffmpeg.org/ffmpeg/trunk
what e.g. RealPlayer does. This allows proper port forwarding setup in NAT-
based environments.
Patch by Martin Storsjö <$firstname at $firstname dot st>.
Originally committed as revision 21856 to svn://svn.ffmpeg.org/ffmpeg/trunk
associated with the I/O handle (e.g. the fd returned by open()). See
"[RFC] rtsp.c EOF support" thread.
There were previously some URI-specific implementations of the same idea,
e.g. rtp_get_file_handles() and udp_get_file_handle(). All of these are
deprecated by this patch and will be removed at the next major API bump.
Originally committed as revision 17779 to svn://svn.ffmpeg.org/ffmpeg/trunk
under review. See "[FFmpeg-devel] RTP mark bit not passed to parse_packet"
thread on mailinglist.
Originally committed as revision 17616 to svn://svn.ffmpeg.org/ffmpeg/trunk
in common except for this one value. Change was requested by Luca in the
"[FFmpeg-devel] RTP mark bit not passed to parse_packet" thread.
Originally committed as revision 17615 to svn://svn.ffmpeg.org/ffmpeg/trunk
