> 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’ 

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 

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.

live-devel mailing list

Reply via email to