Gstreamer with h264 annex b

[Chuck Crisler]

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.

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.

On Fri, Mar 6, 2015 at 9:37 AM, Michał Wróbel <michal.wrobel at flytronic.pl>
wrote:

> 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
>
> michal.wrobel at flytronic.pl
> mobile phone: +48 501 386 897
>
> Flytronic sp. z o.o.
> UAV R&D Center
> www.flytronic.pl
> tel. +48 32 461 23 50
> fax  +48 32 461 23 54
> 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
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150306/15cd6d2f/attachment.html>