Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
gst-rtsp-server
gst-rtsp-server
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 79
    • Issues 79
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 11
    • Merge Requests 11
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GStreamer
  • gst-rtsp-servergst-rtsp-server
  • Issues
  • #80

Closed
Open
Opened Sep 13, 2019 by Sean Halpin@softdev87

TCP Consumers of a Shared Media Factory can block video delivery to other consumers of the same mount point.

Using the gst-rtsp-server example test-launch.c, it is possible for a misbehaving TCP consumer to stop playback to other TCP consumers of a shared media factory.

To replicate the issue;

Launch test-launch with pipeline "videotestsrc ! x264enc ! rtph264pay name=pay0 pt=96"

Consume the stream with 2 ffplay clients with command; ffplay -loglevel trace -rtsp_transport tcp rtsp://127.0.0.1:8554/test

Attach to one ffplay process using gdb so the process is paused. Observe the second ffplay process stops playback.

The issue seems to be in rtsp-stream.c In the func send_tcp_message(), there is a variable that will be increased.

priv->n_outstanding += n_messages * priv->n_tcp_transports;

Then in the func on_message_sent(), that variable should be decremented

priv->n_outstanding--;

In the case where we paused the ffplay process with gdb, on_message_sent() is not called & the variable never decrements. The result is seen in handle_new_sample() callback, where a decision is made to send another tcp message only when

if(priv->n_outstanding == 0)

This means no more data for any of the clients of that shared media.

Edited Sep 13, 2019 by Sean Halpin
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: gstreamer/gst-rtsp-server#80