Trying to stream H264 over RTP

Chuck Crisler ccrisler at mutualink.net
Thu Apr 17 06:54:51 PDT 2014


It isn't easy.

0. If you are accessing an RTSP server it is probably supplied in the SDP.
Done in that case.
1. Grab the SPS and PPS data from the stream, starting with the 0x67 and
0x68 bytes (SPS and PPS NAL type codes). You can get these from a packet
capture.
2. Convert the data of each to a hex string.
3. Base64 encode that string.
4. The sprop-parameter-set is both of those separated by a ','.

The easiest way to do it is to use => http://www.asciitohex.com/

Enter the data in the hexadecimal box and get the Base64 from the Base64
box. Do both fields independently.

You *MAY* not need the sprop-parameter-set. For straight RTP you really
don't. The *ONLY* reason it is needed is for RTSP to satisfy contrary
server implementations (like GStreamer :-) ). The SPS and PPS are almost
always signalled in band in the H264 stream. I have only encountered 1 RTSP
server that doesn't ever signal them in-band. If you are working with a
tablet or mobile device, the SPS and PPS *CHANGE* when the device is
rotated and *MUST* be signalled immediately before the first frame that
uses the new format. An encoder can use up to 16 SPS and 16 PPS records, so
when you change the encoding the encoder might simply generate a second (or
third, whatever) record. That way when the device is rotated back, the
encoder could simply reference the original SPS and PPS. Most decoders
(all? the spec says that they should) would save them so it would work
properly.


On Thu, Apr 17, 2014 at 2:12 AM, Robin Aproskie <raproskie at tellumat.com>wrote:

> Appologies
>
> Michael responded about 3 emails ago with the following pipeline output
>
> ...
> /GstPipeline:pipeline0/GstRtpH264Pay:rtph264pay0: seqnum = 33460
> /GstPipeline:pipeline0/GstUDPSink:udpsink0.GstPad:sink: caps =
> application/x-rtp, media=(string)video, clock-rate=(int)90000,
> encoding-name=(string)H264,
> sprop-parameter-sets=(string)\"Z01AFeygoP2AiAAAAwALuaygAHixbLA\\=\\,aOvssg\\=\\=\",
> payload=(int)96, ssrc=(uint)2406338994, clock-base=(uint)156724985,
> seqnum-base=(uint)33460
> ...
>
> So my question was ?I think aimed at Michael , in the pipeline above how
> do you work out the
> "sprop-parameter-sets"
>
> Thanks
> Robin
>
> -----Original Message-----
> From: gstreamer-devel [mailto:
> gstreamer-devel-bounces at lists.freedesktop.org] On Behalf Of Craig
> Routledge
> Sent: Thursday, April 17, 2014 3:37 AM
> To: Discussion of the development of and with GStreamer
> Subject: Re: Trying to stream H264 over RTP
>
> On 04/16/2014 02:29:23 AM, Robin Aproskie wrote:
> > How do you work out the props?
>
> I'm sorry, I'm new to gstreamer and I don't understand the question.
> Could you be more specific please?
>
>
>
> > -----Original Message-----
> > From: gstreamer-devel
> > [mailto:gstreamer-devel-bounces at lists.freedesktop.org] On Behalf Of
> > Craig Routledge
> > Sent: Wednesday, April 16, 2014 4:47 AM
> > To: Discussion of the development of and with GStreamer
> > Subject: Re: Trying to stream H264 over RTP
> >
> > > On 04/15/2014 01:36 PM, Chuck Crisler wrote:
> > > > Set higher logging levels and/or get a packet capture to see if
> > the
> > > problem(s) is in the transmit or receive.
> >
> > On 04/15/2014 05:46:57 PM, Michael Gruner wrote:
> > > You'll need to specify the full set caps from the payloader, just
> > the
> > > mimetype isn't enough. For example:
> >
> > > And yes, this means that the receiver pipeline is fixed to the
> > sender
> > > pipeline's resolution and characteristics. Changing something on the
> > > sender will require a new pipeline on the receiver. If this is a
> > > problem for you, you might want to try using mpegtsmux or a smarter
> > > protocol like RTSP.
> >
> > Thank you both.  Nothing seemed obviously wrong in the output when I
> > increased the debug level.  However, when I ran wireshark, I got an
> > unending list of "Destination unreachable (unreachable port)" ICMP
> > packets for the destination port.
> >
> > The weird part is that my firewall should not be blocking this.  I'm
> > running Fedora 20 with the standard firewall setup, the first two
> > entries of which are,
> >
> >    -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
> >    -A INPUT -i lo -j ACCEPT
> >
> > So all loopback connections should go through.
> >
> > Anyone have any ideas?
> >
> >
> > Also, I'd like to look into RTSP but although I found a packet
> > receiver
> > (rtspsrc)
> > with gst-inspect, I can't seem to figure out how to invoke the server.
> > The
> > gstreamer-rtsp-server documentation only lists the library functions.
> > Does it
> > have to be done via a program or can I create an RTSP stream with a
> > command line?
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> **********************************************************************
> Relevant company disclaimers are available at the following addresses:
>   Tellumat (Pty) Ltd e-mail:  mailto:disclaimer at tellumat.com
> ?Subject=Tellumat_Disclaimer
>   Web:   http://www.tellumat.com/email.aspx
> **********************************************************************
>
> _______________________________________________
> 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/20140417/05657bdd/attachment.html>


More information about the gstreamer-devel mailing list