[Bug 795570] New: Unexpected error in H264 flow streamed over rtp

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 795570
           Summary: Unexpected error in H264 flow streamed over rtp
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: sancane.kurento at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Hi there!
I'm trying to record an h264 stream that comes over RTP from a browser using
WertRTC (Chrome). It seems to work most of the cases, but I've observed, that
sometimes, the stream begins to be saved but all of a sudden, in the middle of
the recording there is a change in the caps and I get an error that breaks the
media flow in the pipeline.

Next are, roughly speaking, the elements involved in the recording:

(WebRTC/RTP stuff) -> GstRtpH264Depay -> GstH264Parse -> GstMatroskaMux ->
GstFileSink

And here there is the error assotiated to the caps generated by the parser:

Caps not accepted: accept-caps query: 0x7f031c00c6d0, GstQueryAcceptCaps,
caps=(GstCaps)"video/x-h264\,\ stream-format\=\(string\)avc\,\
alignment\=\(string\)au\,\
codec_data\=\(buffer\)0142c015ffe0000f6742c01504032350283e403c2211a8000f6742c0151032350283e403c2211a80000e6742c01528c8d40a0f900f08846a000e6742c0158c8d40a0f900f08846a0000e6742c015432350283e403c2211a8000e6742c015632350283e403c2211a8000e6742c01520c8d40a0f900f08846a000e6742c01530c8d40a0f900f08846a000e6742c01538c8d40a0f900f08846a000f6742c0151432350283e403c2211a80000f6742c0151632350283e403c2211a80000f6742c0151832350283e403c2211a80000f6742c0151a32350283e403c2211a80000f6742c0151c32350283e403c2211a80000f6742c0151e32350283e403c2211a80000f6742c015080c8d40a0f900f08846a0000f6742c015088c8d40a0f900f08846a0000f6742c015090c8d40a0f900f08846a0000f6742c015098c8d40a0f900f08846a0000f6742c0150a0c8d40a0f900f08846a0000f6742c0150a8c8d40a0f900f08846a0000f6742c0150b0c8d40a0f900f08846a0000f6742c0150b8c8d40a0f900f08846a0000f6742c0150c0c8d40a0f900f08846a0000f6742c0150c8c8d40a0f900f08846a0000f6742c0150d0c8d40a0f900f08846a0000f6742c0150d8c8d40a0f900f08846a0000f6742c0150e0c8d40a0f900f08846a0000f6742c0150e8c8d
 40a0f900
 f08846a0000f6742c0150f0c8d40a0f900f08846a0000f6742c0150f8c8d40a0f900f08846a0000f6742c0151232350283e403c2211a80390006680701138f200006680721238f2000056808238f20000468ce3c8000046848e3c80004686ce3c8000568210e3c80000568294e3c80000568318e3c8000056839ce3c800005681020e3c8000568141c38f2000568161d38f2000568181e38f20005681a1f38f20006681c080e3c800004681f38f2000568088a38f2000568090b38f2000568098c38f20005680a0d38f20005680a8e38f20005680b0f38f20006680b840e3c800006680c044e3c800006680c848e3c800006680d04ce3c800006680d850e3c800006680e054e3c800006680e858e3c800006680f05ce3c800006680f860e3c800006680401938f200006680421a38f200006680441b38f200006680461c38f200006680481d38f2000066804a1e38f2000066804c1f38f2000066804e080e3c800056805138f200005680528e3c8000568054ce3c8000568056438f2000568058538f200056805a638f200056805c738f200066805e20e3c8000066806024e3c8000066806228e3c800006680642ce3c8000066806630e3c8000066806834e3c8000066806a38e3c8000066806c3ce3c8000066806e1038f200005681224e3c8\,\
level\=\(string\)2.1\,\ profile\=\(string\)constrained-baseline\,\
parsed\=\(boolean\)true", result=(boolean)false;

I've been trying to debug this issue myself but honestly I don't know where to
start to tackle with this. It seems that whenever the parser provides height
and width in the caps, the emuxer accepts them with no problems, but when this
kind of renegotiation without height and width happens, the muxer reject the
caps and the associated recording fails.

I can not give more details about the issue given that I'm not able to
reproduce this by myself, It only happens when the rtp flow comes from Chrome,
and it does not happens 100% of the times.

Any ideas?

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