GNOME Bugzilla – Bug 778341
rtpjitterbuffer: resetting pts to 0 after gap
Last modified: 2017-02-26 10:42:42 UTC
Created attachment 345217 [details] [review] patch to bypass gap checking for packets with estimated dts In function rtp_jitter_buffer_calculate_pts: If gap in incoming RTP timestamps is more than (3 * jbuf->clock_rate) we call rtp_jitter_buffer_reset_skew which resets pts to 0. So components down the pipeline (playes, mixers) just skip frames/samples until pts becomes equal to pts before gap. In version 1.10.2 and before this checking was bypassed for packets with "estimated dts", and gaps were handled correctly. I created a small patch that fixes this (bypasses checking for "estimated dts" packets like in 1.10.2). Possibly this bypassing was lost after extraction of function rtp_jitter_buffer_calculate_pts.
This didn't make it into 1.10.4 but should really be solved.
commit 76792a5c204dab025ea8c2ce0be865bdca430b98 Author: Andrew <nifigase@gmail.com> Date: Wed Feb 8 13:36:00 2017 +0000 rtpjitterbuffer: Don't always reset PTS to 0 after a gap In function rtp_jitter_buffer_calculate_pts: If gap in incoming RTP timestamps is more than (3 * jbuf->clock_rate) we call rtp_jitter_buffer_reset_skew which resets pts to 0. So components down the pipeline (playes, mixers) just skip frames/samples until pts becomes equal to pts before gap. In version 1.10.2 and before this checking was bypassed for packets with "estimated dts", and gaps were handled correctly. https://bugzilla.gnome.org/show_bug.cgi?id=778341