On Thu, 17 Nov 2011, John Brooks wrote:
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.
Ah, of course. Good, good.
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.
It seems to work fine for me. Yes, if it wrapped before switching to RTCP,
it would have been broken before, too.
Patch applied then.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
