[Live-devel] Avoiding MPEG2-TS packet bursts

[Bruno Abreu]

Hi,

We are using Live555 as our streaming server and we've been facing the
following problem: a significant increase in packet loss is noticeable when a
network gateway is involved, multiple simultaneous Unicast video stream
sessions are requested and is especially bad when it involves the same stream.
This could be nothing or normal 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.

Using Live555 as our server the conditions and symptoms are:
1. using VLC player as client: some video corruption is noticeable with 3
sessions and instability increases in stream decoding just after 4-5 sessions
are created;
2. when using openRTSP QoS stats the increase in packet-loss is measurable.
Please find attached video example with corrupted frames.

We are using old and limited H.264 encoders that don’t provide slice encoding
for bigger frames.
This problem has been happening for long but the analysis wasn't conclusive
until we started doing some experiments with Live555 code.
Initially, to workaround the encoder limitation, we have been using MPEG2-TS
to fragment bigger frames, only now we have some more insight into the
problem.

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

So, picking up on this suggestion:
http://lists.live555.com/pipermail/live-devel/2006-January/003826.html
> A better (or at least easier) solution would be to ensure that there's at
least a minimum delay between successive outgoing packets, so as to not
exceed the overall bit rate of the network.

Lately we've been trying to spread out the packets that make up a given H264
frame in order to minimize the burst of packets on key frames that may lead to
packet loss. We notice this problem especially when streaming several parallel
(from the same live source) unicast sessions.

Implementing the suggested solution led to some improvements. Namely, we were
able to increase the number simultaneous sessions before video corruption
starts to appear. But instead of using a fixed minimum delay, we used a random
delay (from an array of possible values) so that packets are sent out at
different instants by parallel sessions, after seeing three or more
consecutive packets with the same presentation time.
We made a change to MultiFramedRTPSink. Instead of computing uSecondsToGo in
MultiFramedRTPSink::sendPacketIfNecessary(), we created a virtual method where
that calculation is made. Then, we override it in our SimpleRTPSink extension
(please find attached patch and source files).

We are know able to support up to 10 MPEG2-TS clients displaying the same
video source before problems start to appear.

So, after this introduction, we have the following questions:

1. Is this a correct approach? We think the implementation could be improved
if we knew in advance how long for the next presentation time and how many
fragments are still missing from the current frame. Do you have an alternative
suggestion? Maybe changing MPEG2TS Multiplexing from ES Source?

2. Do you think the addition of a virtual method to compute the delay before
sending out the next packet in MultiFramedRTPSink is useful? If so, would you
consider adding it to LIVE555?

Thank you and we welcome any suggestions on improving the analysis and solving
the problem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MultiFramedRTPSink.patch
Type: text/x-patch
Size: 2364 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20160922/91f59a57/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DelayedRTPSink.hh
Type: text/x-c++hdr
Size: 2001 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20160922/91f59a57/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DelayedRTPSink.cpp
Type: text/x-c++src
Size: 3077 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20160922/91f59a57/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: video-MP2T-1
Type: application/octet-stream
Size: 401568 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20160922/91f59a57/attachment.obj>