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

Closed
Open
Created Jan 22, 2016 by Bugzilla Migration User@bugzilla-migration

splitmuxsink: corrupt output when receiving H264 in RTP over UDP and using mpegtsmux

Submitted by Arjen Veenhuizen

Link to original bug (#760980)

Description

We observe that splitmuxsink+mpegtsmux generates corrupt segments when receiving H264 in RTP over UDP. (Note: mp4mux works just fine)

Sender pipeline:
gst-launch-1.0 -eevv videotestsrc ! capsfilter caps="video/x-raw,format=I420,width=1280,height=720,framerate=(fraction)25/1" ! queue ! x264enc key-int-max=25 bitrate=3096 option-string="no-scenecut" bframes=0 ! h264parse config-interval=1 ! rtph264pay ! udpsink port=5004

Receiver pipeline to make sure data is received correctly:
gst-launch-1.0 -eeevv udpsrc port=5004 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, profile-level-id=(string)64001f,payload=(int)96, ssrc=(uint)2359631590, timestamp-offset=(uint)1144720463, seqnum-offset=(uint)20301" ! rtpjitterbuffer ! rtph264depay ! h264parse ! avdec_h264 ! queue ! xvimagesink

Receiver pipeline that generates corrupt MPEG2TS files:

gst-launch-1.0 -eeevv udpsrc port=5004 caps="application/x-rtp,\ media=(string)video,\ clock-rate=(int)90000,\ encoding-name=(string)H264,\ packetization-mode=(string)1,\ profile-level-id=(string)64001f,\ payload=(int)96,\ ssrc=(uint)3675893665,\ timestamp-offset=(uint)1120179275,\ seqnum-offset=(uint)19,\ a-framerate=(string)25" ! rtpjitterbuffer ! rtph264depay ! h264parse ! identity sync=true ! queue ! splitmuxsink muxer=mpegtsmux location=segment_%05d.ts max-size-time=3000001000

We can "play" the first segment, but ffmpeg reports corrupt timestamps. Every subsequent segment is unplayable.

On a side note (but perhaps that should go in a separate bug report?), we cannot pass the sprop-parameter-sets on udpsrc. When we add the following sprop-parameter-sets: sprop-parameter-sets=(string)"Z2QAH6yyAKALdgIgAAADACAAAAZR4wZJ\,aOvMsiw\=",\ in the caps above, gst-launch throws an error about incorrect caps.

e.g

gst-launch-1.0 -eeevv udpsrc port=5004 caps="application/x-rtp,\ media=(string)video,\ clock-rate=(int)90000,\ encoding-name=(string)H264,\ packetization-mode=(string)1,\ profile-level-id=(string)64001f,\ sprop-parameter-sets=(string)"Z2QAH6yyAKALdgIgAAADACAAAAZR4wZJ\,aOvMsiw\=",\ payload=(int)96,\ ssrc=(uint)3675893665,\ timestamp-offset=(uint)1120179275,\ seqnum-offset=(uint)19,\ a-framerate=(string)25" ! rtpjitterbuffer ! rtph264depay ! h264parse ! identity sync=true ! queue ! splitmuxsink muxer=mpegtsmux location=segment_%05d.ts max-size-time=3000001000

Throws this error message: WARNING: erroneous pipeline: could not set property "caps" in element "udpsrc0" to "application/x-rtp,\ media=(string)video,\ clock-rate=(int)90000,\ encoding-name=(string)H264,\ packetization-mode=(string)1,\ profile-level-id=(string)64001f,\ sprop-parameter-sets=(string)"Z2QAH6yyAKALdgIgAAADACAAAAZR4wZJ\,aOvMsiw\=",\ payload=(int)96,\ ssrc=(uint)3675893665,\ timestamp-offset=(uint)1120179275,\ seqnum-offset=(uint)19,\ a-framerate=(string)25"

Not sure whether this problem is related to https://bugzilla.gnome.org/show_bug.cgi?id=752999 (already marked as RESOLVED).

I am on 1.7.0.1, but we have observed the same behavior on other versions (1.6.x) as well. I am also willing to test against git HEAD if that helps.

Assignee
Assign to
Time tracking