On Wed, 9 Nov 2011, John Brooks wrote:
RTCP timestamps are only necessary to synchronize time between multiple streams. For a single stream, the RTP packet timestamp provides more reliable timing. As a result, single-stream RTP sessions should now have accurate and monotonic PTS. --- libavformat/rtpdec.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-)diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c index 1e6bd6e..592c08d 100644 --- a/libavformat/rtpdec.c +++ b/libavformat/rtpdec.c @@ -421,7 +421,10 @@ static void finalize_packet(RTPDemuxContext *s, AVPacket *pkt, uint32_t timestam { if (pkt->pts != AV_NOPTS_VALUE || pkt->dts != AV_NOPTS_VALUE) return; /* Timestamp already set by depacketizer */ - if (s->last_rtcp_ntp_time != AV_NOPTS_VALUE && timestamp != RTP_NOTS_VALUE) { + if (timestamp == RTP_NOTS_VALUE) + return; + + if (s->last_rtcp_ntp_time != AV_NOPTS_VALUE && s->ic->nb_streams > 1) { int64_t addend; int delta_timestamp; @@ -433,8 +436,7 @@ static void finalize_packet(RTPDemuxContext *s, AVPacket *pkt, uint32_t timestam delta_timestamp; return; } - if (timestamp == RTP_NOTS_VALUE) - return; + if (!s->base_timestamp) s->base_timestamp = timestamp; pkt->pts = s->range_start_offset + timestamp - s->base_timestamp; -- 1.7.5.4
The patch in itself looks fine, although checking info via s->ic->nb_streams is kinda ugly (but probably the most straightforward approach here).
The question is whether others think is an acceptable thing to disable RTCP based timestamps completely for this case.
On top of my head, one problem with this is that the RTP based timestamps have a kinda limited range, so the timestamps will wrap around relatively quickly (unless we unwrap them by adding up the differences), which the RTCP based calculation avoided. (A quick calculation says it will wrap around within 13 hours with 90kHz based timing as for MPEG video.)
// Martin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
