[Live-devel] Changing maxPacketSize value for H264VideoRTPSink

Fri Jul 24 06:30:37 PDT 2015

I've added ability to optionally change the packet size with the help of
an environment variable, the executable is always the same.
(The technical details comes after the stat.)

Unfortunately, my application is quite complex, multi-threaded, contains
many layers (video4linux, DSP h264 encoder, ...) and at the moment I
cannot refine the statistics results by leaving only Live part of
application. But the results show big user space numbers (regarding to
the system time) for the default maxPacketSize value.

Here are results (using time utility from BusyBox; tries are separated
by slash in each row):

Default (1456, see MultiFramedRTPSink ctor):

User time (seconds):
        43.08 / 46.08 / 33.89 / 46.28 / 53.94
System time (seconds):
        47.82 / 28.30 / 43.79 / 24.22 / 23.69
Percent of CPU this job got:
        71% / 58% / 61% / 55% / 61%
Elapsed (wall clock) time (h:mm:ss or m:ss):
        2m 7.84s / 2m 7.60s / 2m 6.85s / 2m 7.01s / 2m 6.30s

PACKET_SIZE=2048:

User time (seconds):
        29.05 / 18.41 / 47.89 / 11.57 / 17.63
System time (seconds):
        37.08 / 47.18 / 24.31 / 55.67 / 36.48
Percent of CPU this job got:
        52% / 51% / 56% / 52% / 42%
Elapsed (wall clock) time (h:mm:ss or m:ss):
        2m 7.13s / 2m 7.67s / 2m 7.23s / 2m 7.22s / 2m 6.94s

PACKET_SIZE=4096:

User time (seconds):
        25.21 / 18.73 / 23.99 / 6.71 / 21.29
System time (seconds):
        32.76 / 20.99 / 26.58 / 37.43 / 23.52
Percent of CPU this job got:
        45% / 31% / 39% / 34% / 35%
Elapsed (wall clock) time (h:mm:ss or m:ss):
        2m 6.96s / 2m 7.34s / 2m 7.22s / 2m 6.54s / 2m 7.93s

PACKET_SIZE=8192:

User time (seconds):
        14.95 / 24.76 / 17.58 / 27.76 / 5.37
System time (seconds):
        26.12 / 17.87 / 23.20 / 13.47 / 36.20
Percent of CPU this job got:
        32% / 33% / 32% / 32% / 32%
Elapsed (wall clock) time (h:mm:ss or m:ss):
        2m 7.14s / 2m 6.98s / 2m 6.95s / 2m 6.70s / 2m 7.34s

PACKET_SIZE=12288:

User time (seconds):
        4.10 / 5.41 / 5.56 / 15.13 / 9.53
System time (seconds):
        6.90 / 34.60 / 34.42 / 15.99 / 15.95
Percent of CPU this job got:
        8% / 31% / 31% / 23% / 20%
Elapsed (wall clock) time (h:mm:ss or m:ss):
        2m 6.94s / 2m 7.21s / 2m 6.50s / 2m 9.88s / 2m 6.83s

PACKET_SIZE=16384:

User time (seconds):
        5.29 / 4.94 / 9.72 / 11.84 / 5.67
System time (seconds):
        8.22 / 7.20 / 9.44 / 11.58 / 5.76
Percent of CPU this job got:
        10% / 9% / 14% / 18% / 9%
Elapsed (wall clock) time (h:mm:ss or m:ss):
        2m 7.15s / 2m 7.14s / 2m 8.81s / 2m 6.59s / 2m 6.95s

PACKET_SIZE=20480:

User time (seconds):
        24.05 / 22.31 / 33.34
System time (seconds):
        14.58 / 19.66 / 5.85
Percent of CPU this job got:
        30% / 32% / 30%
Elapsed (wall clock) time (h:mm:ss or m:ss):
        2m 6.69s / 2m 10.02s / 2m 6.83s

PACKET_SIZE=32768:

User time (seconds):
        13.09 / 3.91 / 19.72 / 5.83 / 15.28
System time (seconds):
        25.89 / 23.16 / 16.80 / 7.74 / 25.00
Percent of CPU this job got:
        30% / 21% / 28% / 10% / 31%
Elapsed (wall clock) time (h:mm:ss or m:ss):
        2m 7.51s / 2m 7.72s / 2m 6.64s / 2m 6.66s / 2m 6.64s

Thech details:

Stream: H264 25fps 1920x1080, ~2500000 bytes/sec

root at target:~ uname -a
Linux cvms-cam 2.6.32.24-davinci1-00205-gbc35ad4-dirty #3 PREEMPT Tue
Jun 23 10:31:35 CEST 2015 armv5tejl GNU/Linux

root at target:~ cat /proc/cpuinfo
Processor    : ARM926EJ-S rev 5 (v5l)
BogoMIPS    : 215.44
Features    : swp half thumb fastmult edsp java
CPU implementer    : 0x41
CPU architecture: 5TEJ
CPU variant    : 0x0
CPU part    : 0x926
CPU revision    : 5

root at target:~ /usr/bin/time --help
BusyBox v1.22.0 (2015-05-19 11:47:11 CEST) multi-call binary.

Cross-compiler GCC on the host: arm-none-linux-gnueabi-gcc (Sourcery G++
Lite 2009q3-67) 4.4.1

Parameters of the compilation:
arm-none-linux-gnueabi-g++ -c -Iinclude -I../UsageEnvironment/include
-I../groupsock/include -I. -Os -DSOCKLEN_T=socklen_t
-D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64
-DALLOW_RTSP_SERVER_PORT_REUSE -march=armv5te -mtune=arm926ej-s
-fdata-sections -ffunction-sections -fPIC -DPIC -Wall -DBSD=1 Media.cpp

Best regards,
Max

On 07/23/2015 09:39 PM, Ross Finlayson wrote:
> Increasing the maximum packet size (up to some value < 2^16 bytes) can
> be a good idea if you’re planning to stream only over a LAN.  If,
> however, you’re planning to stream beyond a single LAN, then you
> should be aware that some routers (and/or firewalls) may limit the
> size of network packets that they can forward.  In that case your
> (larger) packets might not get forwarded at all.
>
> As you noted, increasing the packet size reduces the number of network
> packet sends that get done, and thus improves performance (though
> probably mostly due to to reduced OS overhead, not reduced overhead in
> the LIVE555 code).
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20150724/a36a2022/attachment.html>