[gst-devel] rtpbin + mpegtsmux

Marc Leeman marc.leeman at gmail.com
Mon Sep 20 16:07:22 CEST 2010


> > Because that's what the customer wants :-)

Is this what the customer really wants (getting video reliably over the
network) or is it what you've been told the customer wants :-)

> > My understanding is that TS is a container that will eventually contain
> > both video and audio and is not network worthy by itself, hence the RTP
> > (RealTime [network] protocol)

You might have some problems with the timestamps that are in the RTP
header and those that are in TS. If only one is slightly off; you'll run
into problems.

> That said, I've also tried this with a raw H264 stream and the same
> thing happens.
> 
> As I've pointed out, these pipelines do not even work reliably on
> my desktop system all the time.  Using just the raw H264 stream, I
> stream out and in on my desktop, using the local network (127.0.0.1)
> While it may work, even for a while, after some time the receiver no
> longer gets new frames (motion stops).
> 
> Is there some way to get useful debug information on this?  I don't
> see any messages about the RTP stream until level 4 and then it's
> too low level to interpret easily.  I'd like to know when packets
> come in, how they are parsed, passed on, etc, where the keyframes
> are, etc.  This sort of data doesn't seem to show up in the debug
> data.

We've been doing quite some h.264 streaming ourselves; and I can't say
we've had many problems.

There are a number of things you need to take into account.

There are a number of encoders that only send NAL 7/8 once. You can
configure the rtp payloader to re-multipex those on a regular interval
in your stream.

In your case; that will not work since it's not h264 you're sending, but
h264/ts. That's why you can also instruct the h264 parser to re-include
those settings into the stream (before you add the mpeg ts layer).

Our focus is mainly on rtp/h264; but AFAIK; streaming is stable, both
from hardware sources as from x264 sources (and file based).

-- 
  greetz, marc
E = MC ** 2 +- 3db
crichton 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008 GNU/Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20100920/d6c9f009/attachment.pgp>


More information about the gstreamer-devel mailing list