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
  • #748
Closed
Open
Issue created Jun 10, 2020 by Edward Hervey@bilboed🤘Owner

jitterbuffer: Flushing and timer thread

Almost all rtsp seeking validate tests are failing right now, one part of it is related to how jitterbuffer handles flushing.

The timer thread is:

  • Started in READY=>PAUSED (but actually blocked until PAUSED=>PLAYING)
  • Stopped in PAUSED=>READY (but the blocked variable is set in PLAYING=>PAUSED)

The problem is that this assumes that the jitterbuffer:

  • Will only ever go to PLAYING once
  • Will never ever get any FLUSH events (resetting the contents)
  • By extension will never see more than one EOS

If the jitterbuffer receives a flush start/stop events:

  • It won't reset all the timers (especially the EOS one)
  • It won't stop waiting and put itself in a "before anything arrived" state

When the pads are deactivated (PAUSED=>READY) that thread won't put itself in a "Ready to be stoped" state either which can cause various deadlocks

Assignee
Assign to
Time tracking