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
  • #80

Closed
Open
Created 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
Time tracking