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
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
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
The generic default is 0/0 and that obviously triggers once the value is used.
Originally committed as revision 26016 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
This indicates that there was no error that needs to be reported to the
caller, so we can move on to parse the next packet immediately, if
available. The only error code that ff_mpegts_parse_packet can return
indicates that there was no packet to return from the provided data, for
which it returns -1.
Originally committed as revision 25496 to svn://svn.ffmpeg.org/ffmpeg/trunk
It may have returned a negative number for an error (e.g. AVERROR(EAGAIN),
if more data is required for it to be able to return a complete packet).
Originally committed as revision 25458 to svn://svn.ffmpeg.org/ffmpeg/trunk
This fixes roundup issue 2270.
Patch by Robert Schlabbach, robert_s at gmx dot net
Originally committed as revision 25372 to svn://svn.ffmpeg.org/ffmpeg/trunk
Do the same change for ff_rdt_parse_packet, too, to keep the interfaces
similar.
Originally committed as revision 25289 to svn://svn.ffmpeg.org/ffmpeg/trunk
Patch by Josh Allmann, joshua dot allmann at gmail, original code
by Ronald S Bultje.
Originally committed as revision 24236 to svn://svn.ffmpeg.org/ffmpeg/trunk
This allows very large value strings, needed for xiph extradata.
Patch by Josh Allmann, joshua dot allmann at gmail
Originally committed as revision 23859 to svn://svn.ffmpeg.org/ffmpeg/trunk
This will be used for cleaning up code that is common among RTP depacketizers.
Patch by Josh Allmann, joshua dot allmann at gmail
Originally committed as revision 23847 to svn://svn.ffmpeg.org/ffmpeg/trunk
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
the Vorbis / theora depacketizers.
Patch by Josh Allmann <joshua DOT allmann AT gmail DOT com>.
Originally committed as revision 22765 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
