[Bug 760980] New: [splitmuxsink] corrupt output when receiving H264 in RTP over UDP and using mpegtsmux

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=760980

            Bug ID: 760980
           Summary: [splitmuxsink] corrupt output when receiving H264 in
                    RTP over UDP and using mpegtsmux
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: arjen.veenhuizen at tno.nl
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.