GNOME Bugzilla – Bug 795570
Unexpected error in H264 flow streamed over rtp
Last modified: 2018-08-01 13:58:55 UTC
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\)0142c015ffe0000f6742c01504032350283e403c2211a8000f6742c0151032350283e403c2211a80000e6742c01528c8d40a0f900f08846a000e6742c0158c8d40a0f900f08846a0000e6742c015432350283e403c2211a8000e6742c015632350283e403c2211a8000e6742c01520c8d40a0f900f08846a000e6742c01530c8d40a0f900f08846a000e6742c01538c8d40a0f900f08846a000f6742c0151432350283e403c2211a80000f6742c0151632350283e403c2211a80000f6742c0151832350283e403c2211a80000f6742c0151a32350283e403c2211a80000f6742c0151c32350283e403c2211a80000f6742c0151e32350283e403c2211a80000f6742c015080c8d40a0f900f08846a0000f6742c015088c8d40a0f900f08846a0000f6742c015090c8d40a0f900f08846a0000f6742c015098c8d40a0f900f08846a0000f6742c0150a0c8d40a0f900f08846a0000f6742c0150a8c8d40a0f900f08846a0000f6742c0150b0c8d40a0f900f08846a0000f6742c0150b8c8d40a0f900f08846a0000f6742c0150c0c8d40a0f900f08846a0000f6742c0150c8c8d40a0f900f08846a0000f6742c0150d0c8d40a0f900f08846a0000f6742c0150d8c8d40a0f900f08846a0000f6742c0150e0c8d40a0f900f08846a0000f6742c0150e8c8d40a0f900f08846a0000f6742c0150f0c8d40a0f900f08846a0000f6742c0150f8c8d40a0f900f08846a0000f6742c0151232350283e403c2211a80390006680701138f200006680721238f2000056808238f20000468ce3c8000046848e3c80004686ce3c8000568210e3c80000568294e3c80000568318e3c8000056839ce3c800005681020e3c8000568141c38f2000568161d38f2000568181e38f20005681a1f38f20006681c080e3c800004681f38f2000568088a38f2000568090b38f2000568098c38f20005680a0d38f20005680a8e38f20005680b0f38f20006680b840e3c800006680c044e3c800006680c848e3c800006680d04ce3c800006680d850e3c800006680e054e3c800006680e858e3c800006680f05ce3c800006680f860e3c800006680401938f200006680421a38f200006680441b38f200006680461c38f200006680481d38f2000066804a1e38f2000066804c1f38f2000066804e080e3c800056805138f200005680528e3c8000568054ce3c8000568056438f2000568058538f200056805a638f200056805c738f200066805e20e3c8000066806024e3c8000066806228e3c800006680642ce3c8000066806630e3c8000066806834e3c8000066806a38e3c8000066806c3ce3c8000066806e1038f200005681224e3c8\,\ 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?
matroskamux can't deal with caps changing (it would accept that in older versions but produce broken files). You need to use a different container like mpeg-ts that can handle that. Or are you saying that the format doesn't really change and it's just that the way the parser and muxer interact that causes problems when there shouldn't be any? I think you'd have to try and get a wireshark capture or so.
that's strange because I've being testing changes of caps (hight and width) and works well, the file generated fits to the new size. Nevertheless, the pipeline only seems to break when the caps provided by the parser do not include hight and width.
What version are you on? This is something we got stricter about in 1.14. Either way, I think you need to find a way to reproduce it, e.g. with a capture.
just to be sure: matroskamux takes AVC caps as input, so h264parse should never output caps without width and height in this case.
Hello Tim, first of all thanks for the feedback. I think that this issue is strongly related to this other: https://bugzilla.gnome.org/show_bug.cgi?id=782949 Do you have any pointer to a "kind of matroska spec regarding H264" followed by GStreamer implementation? We have strong requirements to have a unique matroska file and we would like to know the restrictions we have to deal with.
Miguel, if you cannot update the PPS/SPS on the fly, then you must have multiple PPS/SPS all together at the start. This is the only valid way to get dynamic resolution from a single matroska file. This cannot be done generically from a webrtc source.