Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • gst-rtsp-server gst-rtsp-server
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 92
    • Issues 92
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 10
    • Merge requests 10
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GStreamer
  • gst-rtsp-servergst-rtsp-server
  • Issues
  • #23

Closed
Open
Created Jun 07, 2016 by Bugzilla Migration User@bugzilla-migration

Uses the same thread for multiple clients and blocks them on media preparation, leads to deadlocks

Submitted by Sebastian Dröge @slomo

Link to original bug (#767333)

Description

Currently when a client connects, a thread is assigned to this client and everything that happens with this client happens on that thread. By itself this is not a problem, but unfortunately from this very thread the rtsp-media is also waiting synchronously to be prepared.

This means that while the media is being prepared, no other client that uses the same thread can send requests or get responses. And especially this can lead to various deadlock situations, for example:

  • two clients are connecting and creating a media (one for each) that is fed from an appsrc
  • the appsrcs are both fed from the same, other pipeline
  • the first client finishes preparing the media (-> the pipeline is blocked)
  • the second client starts preparing the media
  • the other pipeline is blocking because the first appsrc is blocked
  • the second appsrc never gets enough data to preroll, and the first appsrc is never unblocked because the client has no way to send its PLAY request to unblock the pipeline

We should wait asynchronously for the media to be prepared, which unfortunately requires a few changes in the way how rtsp-client.c works. Currently request-response is a completely synchronous process.

Version: 1.8.1

Assignee
Assign to
Time tracking