[Live-devel] Avoiding MPEG2-TS packet bursts

[Ross Finlayson]

> but we are talking of a company internal wired
> network with multiple Gbps capacity. Because of this we are pinning the
> problem in the network gateway capacity to handle instant bursts of packets,
> no matter the size, small or big.

So, have you talked to your network gateway’s vendor about this problem?  After all, (unlike our software) you have paid actual money for this hardware :-)


> We are using old and limited H.264 encoders that don’t provide slice encoding
> for bigger frames.

As you know (from my numerous postings on this topic :-), such a H.264 encoder is bad (inappropriate) for streaming, because large 'key frame' NAL units end up getting fragmented over a very large number of RTP packets, and the loss of just one of these RTP packets will leave the whole ‘key frame’ undecodable/unrenderable.

So, please consider replacing/upgrading your H.264 encoders.  (Perhaps use some of the money that you’ve saved on software :-)


In any case, I won’t be changing “MultiFramedRTPSink”, because the code is already very complex, yet it’s already working properly.  The “uSecondsToGo” variable is already being computed correctly - based on the durations (i.e., “fDurationInMicroseconds”) of the input frames.  The reason why you’re seeing a “uSecondsToGo” value of 0 for each of your RTP packets is because the input source is not setting “fDurationInMicroseconds”, thereby leaving it at its default value of 0.  That’s perfectly OK, though, because your input source is a live stream, rather than a prerecorded file.

But the problem you’re having is - as you noted - that you’re sending bursts of a large number of RTP packets, spaced closely together.  Note that each of your RTP packets is just 224 bytes long (188-byte Transport Stream ‘packet’ size + RTP,UDP,IP headers).  If, instead, you accumulated several 188-byte Transport Stream ‘packets’ into a single RTP payload, you’d end up transmitting many fewer packets (and with less header overhead) - which may well overcome your problem

I have just installed a new version (2016.09.22) of the “LIVE555 Streaming Media” software that adds a new ‘filter’ class “MPEG2TransportStreamAccumulator” that gathers multiple 188-byte Transport Stream ‘packets’ into a larger payload, for streaming.  (By default, the code gathers 7 Transport Stream ‘packets’ - i.e., for a 1316-byte payload, which is just less than the typical Ethernet MTU.)

> MPEG2-TS streaming pipeline:
> DeviceSource -> StreamReplica -> H264VideoStreamDiscreteFramer ->
> MPEG2TransportStreamFromESSource -> SimpleRTPSink

I suggest adding a “MPEG2TransportStreamAccumulator” between the “MPEG2TransportStreamFromESSource” and the “SimpleRTPSink”.  This will reduce (by 7 times) the number of packets that you transmit, and also reduce your total bitrate by about 14%.


If that doesn’t solve your problem (though I think it will), then one more thing you could try is adding a “MPEG2TransportStreamFramer” between the “MPEG2TransportStreamAccumulator” and the “SimpleRTPSink”.  The “MPEG2TransportStreamFramer” will estimate the duration of each Transport ‘packet’, and will set “fDurationInMicroseconds” appropriately.  This will likely cause the output RTP packets to be less ‘bursty’, and the cost of a little extra CPU overhead.  However, I don’t recommend doing this unless the “MPEG2TransportStreamAccumulator” alone doesn’t overcome your problem.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/