Suppose we have a frame being transmitted in 10 packets with timestamp
X. Our RTP timestamp rewriting is supposed to rewrite X -> Y. We have
observed that, under certain circumstances, our RTP timestamp rewriting
can start by rewriting X -> Y for the first few packets, and then X -> Z
for the rest of the packets. The circumstances under which this problem
manifests is when we receive an update for the remote clock -through RTCP-.
You can view, comment on, or merge this pull request online at:
-- Commit Summary --
* Attempts to fix frequent short freezes.
-- File Changes --
M src/org/jitsi/impl/neomedia/transform/rewriting/SsrcRewriter.java (33)
M src/org/jitsi/impl/neomedia/transform/rewriting/SsrcRewritingEngine.java (56)
-- Patch Links --
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: