Skip to content

GitLab

  • Menu
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 648
    • Issues 648
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 82
    • Merge requests 82
  • 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-plugins-goodgst-plugins-good
  • Issues
  • #797

Closed
Open
Created Oct 15, 2020 by Stian Berglie@berglie

rtspsrc: Use fallback stream when getting invalid transport headers

When trying to connect to a stream where the server replies with invalid headers we get 'Server did not select transport' error and the stream is not played. This happens even if the video transport header is ok and audio transport is the only invalid header.

If the audio transport header parsing fails, it should try parsing the video transport header and show stream without audio if parsing of video header is fine. And also vice-versa.

The same stream with invalid audio transport header is tested and shown to be supported by several other media player such as VLC, where the stream will be shown without the audio track.

Ref. issue #787, where the audio transport header was invalid from server side:

0:00:00.997070000 7576 126F3378 LOG rtspsrc gstrtspsrc.c:9647:dump_key_value:<source> key: 'Transport', value: 'Transport: RTP/AVP;unicast;client_port=59576-59577;server_port=21438-21439;source=192.168.105.5;destination=192.168.5.1'

Quote @slomo comment:

The problem is that the server is sending Transport: Transport: RTP/AVP..., so sending an invalid Transport header that has the header name duplicated in the value. So a broken server here

The issue was solved by fixing the header from server side in this case, but it would be nice to have a fallback in case it should happen with other servers as well.

Edited Oct 15, 2020 by Stian Berglie
Assignee
Assign to
Time tracking