<div dir="ltr"><div>There are situations where in-band signaling is absolutely needed and required for successful video operations. Specifically, if you have video originating with a mobile device that has different sizes for different orientations, then when the device is rotated 90 degrees, you need to send the SPS/PPS pair to help correct the final display. Also, the application that I have developed has 1 system that receives video from a network source and then propagates it to other systems that join at different times. If there is only a SPS/PPS at the start, later joining endpoints won't ever succeed in decoding video. I have extended the rtph264depay element to also have a config-interval property, which solved that problem because there are IP cameras (Axis) that don't send the in-band signaling. </div>Though UDP is defined as 'unreliable', repeating the SPS/PPS every 2-5 seconds doesn't have any real impact of bandwidth usage and if you are losing enough packets that they never get through, the lack of SPS/PPS packets isn't your real problem. </div><div class="gmail_extra"> <div class="gmail_quote">On Fri, Mar 6, 2015 at 9:37 AM, Michał Wróbel <<a href="mailto:michal.wrobel@flytronic.pl" target="_blank">michal.wrobel@flytronic.pl</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 05.03.2015 13:06, sivan wrote: > When I open it with wireshark, I see the format is different then annex b: > > I don't see the 00 00 00 01 sequence that suppose to be in the beginning of > each frame That's perfectly OK. Actually, RFC6184 specifies that 00 00 00 01 sequence inside an RTP packet would be an error: "This payload specification can only be used to carry the "naked" H.264 NAL unit stream over RTP and not the bitstream format discussed in Annex B of H.264." Please, don't violate this rule. Even if many H.264 stream receivers seem to parse such packets without any error or warning. On 05.03.2015 14:43, sivan wrote: > How can I use the current gstreamer to get the h264 frames and I also need the sps and pps from the stream According to RFC6184, it is acceptable to have SPS and PPS inside an RTP packet stream. It is called "in-band signalling of parameter sets". However, it is not recommended when an unreliable medium is used: "If in-band signaling of parameter sets is used, the sender SHOULD take the error characteristics into account and use mechanisms to provide a high probability for delivering the parameter sets correctly. Mechanisms that increase the probability for a correct reception include packet repetition, FEC, and retransmission. The use of an unreliable, out-of-band control protocol has similar disadvantages as the in-band signaling (possible loss) and, in addition, may also lead to difficulties in the synchronization (see below). Therefore, it is NOT RECOMMENDED." It may be done to work reliably, but requires some special attention. Many receivers/decoders will wait for SPS/PPS before attempting to decode the video. Some do not - they try their best to decode, most of the time without success, which results in a glitch when starting to receive the stream. An typical out-of-the-band signaling of parameter sets is to provide description of the session via SDP (in a file or on-line via RTSP - check out gst-rtsp-server). Having that said... if you still want to just stream RTP with in-band signalling, here's a gst-launch oneliner for x264enc: gst-launch-1.0 videotestsrc ! 'video/x-raw, framerate=30/1, width=640, height=480' ! queue ! x264enc tune=4 ! rtph264pay ! udpsink host=224.0.0.1 port=5000 However, here it is x264enc which inserts SPS/PPS into the stream at each keyframe. If you have a stream without SPS/PPS (from some other encoder), use config-interval property of rtph264pay. Best regards, Michał Wróbel -- Michał Wróbel Software developer <a href="mailto:michal.wrobel@flytronic.pl">michal.wrobel@flytronic.pl</a> mobile phone: <a href="tel:%2B48%20501%20386%20897" value="+48501386897">+48 501 386 897</a> Flytronic sp. z o.o. UAV R&D Center <a href="http://www.flytronic.pl" target="_blank">www.flytronic.pl</a> tel. <a href="tel:%2B48%2032%20461%2023%2050" value="+48324612350">+48 32 461 23 50</a> fax <a href="tel:%2B48%2032%20461%2023%2054" value="+48324612354">+48 32 461 23 54</a> ul. Bojkowska 43, 44-100 Gliwice NIP:969 151 39 93, REGON: 240851769, KRS 0000298330, Sąd Rejonowy w Gliwicach, X Wydział Gospodarczy Krajowego Rejestru Sądowego -- Niniejsza wiadomość jest przeznaczona tylko dla jej adresata i nie może być ujawniona osobom trzecim. Jeśli nie jest Pan/i zamierzonym adresatem niniejszej wiadomości bądź osobą przez niego upoważnioną do jej odbioru lub przekazania adresatowi, informujemy, że jej rozpowszechnianie, dystrybucja, kopiowanie lub inne działanie o podobnym charakterze jest zabronione. Jeżeli wiadomość dotarła do Pan/i omyłkowo, prosimy o poinformowanie nadawcy oraz usunięcie wiadomości z poczty bez otwierania załączników. Dziękujemy. This e-mail is intended solely for the addressee(s) and must not be disclosed to third parties. If you are not the addressee of this e-mail or has not been authorized by the addressee to receive or forward this message, we inform that its disclosure, distribution, copying or any other similar action is unlawful. If you have received this e-mail in error, please notify the sender immediately by return e-mail. Please then delete the e-mail from your mail box without opening attachments. Thank you. -- _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </blockquote></div> </div>