On Thu, Nov 17, 2011 at 4:23 PM, Martin Storsjö <[email protected]> wrote: > On Thu, 17 Nov 2011, John Brooks wrote: > >> diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c >> index 592c08d..88cf15b 100644 >> --- a/libavformat/rtpdec.c >> +++ b/libavformat/rtpdec.c >> @@ -439,7 +439,13 @@ static void finalize_packet(RTPDemuxContext *s, >> AVPacket *pkt, uint32_t timestam >> >> if (!s->base_timestamp) >> s->base_timestamp = timestamp; >> - pkt->pts = s->range_start_offset + timestamp - s->base_timestamp; >> + /* assume that the difference is INT32_MIN < x < INT32_MAX, but allow >> the first timestamp to exceed INT32_MAX */ >> + if (!s->timestamp) >> + s->unwrapped_timestamp += timestamp; > > In this case, I guess unwrapped_timestamp always is 0, so += and = would do > the same, right? (Using = would feel more intuitive to me, but it's no big > deal.) >
If the previous timestamp wrapped to exactly 0, we'll hit this case when unwrapped_timestamp is non-zero, so the addition is correct. > Except for this, I'll have to think it through to make sure there's no case > where this causes a difference to the current code, when switching from > RTP-only to RTCP-based timestamps. > Please do. I tried very carefully avoid changing behavior, but I might've missed something. As far as I can tell, the only behavior changes from this patch are that wrapping works, and timestamps with a difference not of INT_MIN <= x <= INT_MAX won't work (can that happen from seeking? I don't believe so). Behavior would be wrong if the timestamp wrapped before the first RTCP packet when using RTCP, but not more wrong than it was before. I'll look at handling that (exceedingly rare) case when I figure out a way to revise RTCP-based PTS. Thanks - John _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
