[Live-devel] Avoiding MPEG2-TS packet bursts

[Bruno Abreu]

On 09/23/2016 12:26 AM, Ross Finlayson wrote:
> 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.
OK. So, we take it MultiFramedRTPSink is not a good place to introduce 
such changes.
Would it be reasonable something with our own filter that estimated the 
fDurationInMicroseconds for each Transport Stream 'packet' based on a 
know frame rate, and adjusting the inter-frame gap to a inter-packet 
gap? Much like you suggestion for the use of a 
"MPEG2TransportStreamFramer" below?
We are inclined to try it since the use of the 
"MPEG2TransportStreamAccumulator" didn't yield the expected outcome (see 
below).


> 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%.
Well, thank you for this, Ross.
But the thing is, as far as we can tell by using testRTSPClient, there 
is no difference in using "MPEG2TransportStreamAccumulator" on the 
server or not. We always get the same output and it appears to us we are 
receiving 6 Transport Stream 'packets' at a time (please find attached 
log files).


> 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.
I'm afraid I didn't notice any improvement with 
MPEG2TransportStreamAccumulator or MPEG2TransportStreamAccumulator + 
MPEG2TransportStreamFramer.


Anyway, thank you very much for your suggestions and support.

Bruno Abreu


-- 
Living Data - Sistemas de Informação e Apoio à Decisão, Lda.

LxFactory - Rua Rodrigues de Faria, 103,
edifício I - 4º piso                  Phone:  +351 213622163
1300-501 LISBOA                       Fax:    +351 213622165
Portugal                              URL: www.livingdata.pt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testRTSPClient-server_with_accumulator.log
Type: text/x-log
Size: 94540 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20160927/f53a4c61/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testRTSPClient-server_without_accumulator.log
Type: text/x-log
Size: 95422 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20160927/f53a4c61/attachment-0001.bin>