Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • gst-plugins-good gst-plugins-good
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 646
    • Issues 646
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 71
    • Merge requests 71
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GStreamerGStreamer
  • gst-plugins-goodgst-plugins-good
  • Issues
  • #611
Closed
Open
Issue created Jun 13, 2019 by Nicolas Dufresne@ndufresneMaintainer

rtpjitterbuffer: Timers using ranges (senum + num) won't be found by find_timers

This is a random issue I have seen. While we do use range in timers, we don't have a proper implementation for that. Right now, we only use ranges when for LOST timer where the timer is already past. Yet, this can have side effect, since find_timers() won't match any timers if you get a packet with seqnum + 1. Fortunately, the already_lost() function will catch most of the packets, but there is still some possible issues. So after the LOST timer has been converted into lost even and push in the jitterbuffer, but before it is pushed, the jitterbuffer won't notice the duplicate. Then after we have pushed the lost, the remaining seqnum will be dropped based on "last_popped_seqnum", which is set to the start of the range, hence won't match the conditions for the normal already lost packets. We have other hacks to catch this up, so I suppose no bad packets are pushed, but I'm pretty sure it can break the stats.

cc @hgr

Assignee
Assign to
Time tracking