This is not intended as a bug report--even if these leaks may be a result of mpl bugs, please interpret the question ask asking for a way around them.
The problem is simple: plot a large chunk of data (using plot() or scatter()), clear/release everything, garbage collect, but still not nearly all the memory is released.
Line # Mem usage Increment Line Contents
================================================
391 122.312 MiB 0.000 MiB #profile
392 def plot_network_scatterplot(t_sim_stop, spikes_mat, n_cells_per_area, n_cells, basedir_output, condition_idx):
393
394 # make network scatterplot
395 122.312 MiB 0.000 MiB w, h = plt.figaspect(.1/(t_sim_stop/1E3))
396 122.324 MiB 0.012 MiB fig = mpl.figure.Figure(figsize=(10*w, 10*h))
397 122.328 MiB 0.004 MiB canvas = FigureCanvas(fig)
398 122.879 MiB 0.551 MiB ax = fig.add_axes([.01, .1, .98, .8])
399 134.879 MiB 12.000 MiB edgecolor_vec = np.array([(1., 0., 0.), (0., 0., 1.)])[1-((spikes_mat[:,3]+1)/2).astype(np.int)]
400 '''pathcoll = ax.scatter(spikes_mat[:,1],
401 spikes_mat[:,0] + n_cells_per_area * (spikes_mat[:,2]-1),
402 s=.5,
403 c=spikes_mat[:,3],
404 edgecolor=edgecolor_vec)'''
405 440.098 MiB 305.219 MiB pathcoll = ax.plot(np.random.rand(10000000), np.random.rand(10000000))
406 440.098 MiB 0.000 MiB ax.set_xlim([0., t_sim_stop])
407 440.098 MiB 0.000 MiB ax.set_ylim([1, n_cells])
408 440.098 MiB 0.000 MiB plt.xlabel('Time [ms]')
409 440.098 MiB 0.000 MiB plt.ylabel('Cell ID')
410 440.098 MiB 0.000 MiB plt.suptitle('Network activity scatterplot')
411 #plt.savefig(os.path.join(basedir_output, 'network_scatterplot-[cond=' + str(condition_idx) + '].png'))
412 931.898 MiB 491.801 MiB canvas.print_figure(os.path.join(basedir_output, 'network_scatterplot-[cond=' + str(condition_idx) + '].png'))
413 #fig.canvas.close()
414 #pathcoll.set_offsets([])
415 #pathcoll.remove()
416 931.898 MiB 0.000 MiB ax.cla()
417 931.898 MiB 0.000 MiB ax.clear()
418 931.898 MiB 0.000 MiB fig.clf()
419 931.898 MiB 0.000 MiB fig.clear()
420 931.898 MiB 0.000 MiB plt.clf()
421 932.352 MiB 0.453 MiB plt.cla()
422 932.352 MiB 0.000 MiB plt.close(fig)
423 932.352 MiB 0.000 MiB plt.close()
424 932.352 MiB 0.000 MiB del fig
425 932.352 MiB 0.000 MiB del ax
426 932.352 MiB 0.000 MiB del pathcoll
427 932.352 MiB 0.000 MiB del edgecolor_vec
428 932.352 MiB 0.000 MiB del canvas
429 505.094 MiB -427.258 MiB gc.collect()
430 505.094 MiB 0.000 MiB plt.close('all')
431 505.094 MiB 0.000 MiB gc.collect()
I have tried many combinations and different orders of all the clear/release to no avail. I've tried not using an explicit fig/canvas creation but just using mpl.pyplot, with the same results.
Is there any way to free this memory, and go out with the 122.312 that I came in?
Cheers!
Alex Martelli explains
It's very hard, in general, for a process to "give memory back to the OS"
(until the process terminates and the OS gets back all the memory, of course)
because (in most implementation) what malloc returns is carved out of big blocks
for efficiency, but the whole block can't be given back if any part of it is
still in use." So what you think is a memory leak may just be a side effect of
this. If so, fork can solve the problem.
Furthermore,
The only really reliable way to ensure that a large but
temporary use of memory DOES return all resources to the system when it's done,
is to have that use happen in a subprocess, which does the memory-hungry work
then terminates."
Therefore, you instead of trying to clear the figure and axes, delete references and garbage collecting (all of which will not work), you can instead use multiprocessing to run plot_network_scatterplot in a separate process:
import multiprocessing as mp
def plot_network_scatterplot(
t_sim_stop, spikes_mat, n_cells_per_area, n_cells, basedir_output,
condition_idx):
# make network scatterplot
w, h = plt.figaspect(.1/(t_sim_stop/1E3))
fig = mpl.figure.Figure(figsize=(10*w, 10*h))
canvas = FigureCanvas(fig)
ax = fig.add_axes([.01, .1, .98, .8])
edgecolor_vec = np.array([(1., 0., 0.), (0., 0., 1.)])[1-((spikes_mat[:,3]+1)/2).astype(np.int)]
'''pathcoll = ax.scatter(spikes_mat[:,1],
spikes_mat[:,0] + n_cells_per_area * (spikes_mat[:,2]-1),
s=.5,
c=spikes_mat[:,3],
edgecolor=edgecolor_vec)'''
pathcoll = ax.plot(np.random.rand(10000000), np.random.rand(10000000))
ax.set_xlim([0., t_sim_stop])
ax.set_ylim([1, n_cells])
plt.xlabel('Time [ms]')
plt.ylabel('Cell ID')
plt.suptitle('Network activity scatterplot')
canvas.print_figure(os.path.join(basedir_output, 'network_scatterplot-[cond=' + str(condition_idx) + '].png'))
def spawn(func, *args):
proc = mp.Process(target=func, args=args)
proc.start()
# wait until proc terminates.
proc.join()
if __name__ == '__main__':
spawn(plot_network_scatterplot, t_sim_stop, spikes_mat, n_cells_per_area,
n_cells, basedir_output, condition_idx)
Related
I'm trying to detect a memory leak location for a certain process via Windbg, and have come across a strange problem.
Using windbg, I've created 2 memory dump snapshots - one before and one after the leak, that showed an increase of around 20MBs (detected via Performance Monitor - private bytes). it shows that there is indeed a similar size difference in one of the heaps before and after the leak (Used with the command !heap -s):
Before:
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-----------------------------------------------------------------------------
03940000 08000002 48740 35312 48740 4372 553 9 5 2d LFH
External fragmentation 12 % (553 free blocks)
03fb0000 08001002 7216 3596 7216 1286 75 4 8 0 LFH
External fragmentation 35 % (75 free blocks)
05850000 08001002 60 16 60 5 2 1 0 0
...
After:
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-----------------------------------------------------------------------------
03940000 08000002 64928 55120 64928 6232 1051 26 5 51 LFH
External fragmentation 11 % (1051 free blocks)
03fb0000 08001002 7216 3596 7216 1236 73 4 8 0 LFH
External fragmentation 34 % (73 free blocks)
05850000 08001002 60 16 60 5 2 1 0 0
...
See the first Heap (03940000) - there is a difference in committed KBs of around 55120 - 35312 = 19808 KB = 20.2 MB.
However, when I inspected that heap with (!heap -stat -h 03940000), it displays the following for both dump files:
size #blocks total ( %) (percent of total busy bytes)
3b32 1 - 3b32 (30.94)
1d34 1 - 1d34 (15.27)
880 1 - 880 (4.44)
558 1 - 558 (2.79)
220 1 - 220 (1.11)
200 2 - 400 (2.09)
158 1 - 158 (0.70)
140 2 - 280 (1.31)
...(rest of the lines show no difference)
size #blocks total ( %) (percent of total busy bytes)
3b32 1 - 3b32 (30.95)
1d34 1 - 1d34 (15.27)
880 1 - 880 (4.44)
558 1 - 558 (2.79)
220 1 - 220 (1.11)
200 2 - 400 (2.09)
158 1 - 158 (0.70)
140 2 - 280 (1.31)
...(rest of the lines show no difference)
As you can see, there is hardly a difference between the two, despite the abovementioned 20MB size difference.
Is there an explanation for that?
Note: I have also inspected the Unmanaged memory using UMDH - there wasn't a noticeable size difference there.
so I've searched this online and this is a pretty common error but I've tried the given solutions to no avail. My cmd log is:
C:\Users\kosyn_000\Dropbox\OpenCVtrainingdata>opencv_traincascade -data my_trained -vec positives.vec -bg negativedata.txt -numPos 30 -numNeg 76 -numStages 15 -minHitRate 0.995 -w 197 -h 197 -featureType LBP -precalcValBufSize 1024 -precalcIdxBufSize 1024
PARAMETERS:
cascadeDirName: my_trained
vecFileName: positives.vec
bgFileName: negativedata.txt
numPos: 30
numNeg: 76
numStages: 15
precalcValBufSize[Mb] : 1024
precalcIdxBufSize[Mb] : 1024
acceptanceRatioBreakValue : -1
stageType: BOOST
featureType: LBP
sampleWidth: 197
sampleHeight: 197
boostType: GAB
minHitRate: 0.995
maxFalseAlarmRate: 0.5
weightTrimRate: 0.95
maxDepth: 1
maxWeakCount: 100
Number of unique features given windowSize [197,197] : 41409225
===== TRAINING 0-stage =====
<BEGIN
POS count : consumed 30 : 30
Train dataset for temp stage can not be filled. Branch training terminated.
Cascade classifier can't be trained. Check the used training parameters.
C:\Users\kosyn_000\Dropbox\OpenCVtrainingdata>
and my negativedata.txt file has 76 lines of info in the form:
negatives/1411814567410.jpg 1 2 2 199 199
negatives/20131225_192702.jpg 1 2 2 199 199
negatives/20131225_193214.jpg 1 2 2 199 199
negatives/20131225_193325.jpg 1 2 2 199 199
negatives/20131225_193327.jpg 1 2 2 199 199
negatives/20131225_193328.jpg 1 2 2 199 199
Please can someone help me pinpoint the issue because I'm still not sure why I'm getting this error. I'm doing this on a windows system. Thank you.
Found out the issue, apparently the bg file shouldn't contain constraints so now my file is in the form
C:\Users\kosyn_000\Dropbox\OpenCVtrainingdata\negatives/ff.JPG
C:\Users\kosyn_000\Dropbox\OpenCVtrainingdata\negatives/fifa.JPG
C:\Users\kosyn_000\Dropbox\OpenCVtrainingdata\negatives/fred.JPG
C:\Users\kosyn_000\Dropbox\OpenCVtrainingdata\negatives/IMG-20140718-WA0008-1.jpg
C:\Users\kosyn_000\Dropbox\OpenCVtrainingdata\negatives/IMG-20150102-WA0013.jpg
C:\Users\kosyn_000\Dropbox\OpenCVtrainingdata\negatives/IMG-20150120-WA0005.jpg
C:\Users\kosyn_000\Dropbox\OpenCVtrainingdata\negatives/IMG_20140109_012313.jpg
C:\Users\kosyn_000\Dropbox\OpenCVtrainingdata\negatives/IMG_20140405_205621.jpg
C:\Users\kosyn_000\Dropbox\OpenCVtrainingdata\negatives/IMG_20140405_214225.jpg
C:\Users\kosyn_000\Dropbox\OpenCVtrainingdata\negatives/IMG_20140405_214225_transparent.png
C:\Users\kosyn_000\Dropbox\OpenCVtrainingdata\negatives/IMG_20140405_214225_transparent_small.png
and it outputted my xml file fine; albeit taking a bit of time. Lol I can't believe it was something so simple holding me back.
I am getting both of these errors at the same time. I can't decrease the pg count and I can't add more storage.
This is a new cluster, and I got these warning when I uploaded about 40GB to it. I guess because radosgw created a bunch of pools.
How can ceph have too many pgs per osd, yet have more object per pg than average with a too few pgs suggestion?
HEALTH_WARN too many PGs per OSD (352 > max 300);
pool default.rgw.buckets.data has many more objects per pg than average (too few pgs?)
osds: 4 (2 per site 500GB per osd)
size: 2 (cross site replication)
pg: 64
pgp: 64
pools: 11
Using rbd and radosgw, nothing fancy.
I'm going to answer my own question in hopes that it sheds some light on the issue or similar misconceptions of ceph internals.
Fixing HEALTH_WARN too many PGs per OSD (352 > max 300) once and for all
When balancing placement groups you must take into account:
Data we need
pgs per osd
pgs per pool
pools per osd
the crush map
reasonable default pg and pgp num
replica count
I will use my set up as an example and you should be able to use it as a template for your own.
Data we have
num osds : 4
num sites: 2
pgs per osd: ???
pgs per pool: ???
pools per osd: 10
reasonable default pg and pgp num: 64 (... or is it?)
replica count: 2 (cross site replication)
the crush map
ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY
root ourcompnay
site a
rack a-esx.0
host prdceph-strg01
osd.0 up 1.00000 1.00000
osd.1 up 1.00000 1.00000
site b
rack a-esx.0
host prdceph-strg02
osd.2 up 1.00000 1.00000
osd.3 up 1.00000 1.00000
Our goal is to fill in the '???' above with what we need to serve a HEALTH OK cluster. Our pools are created by the rados gateway when it initialises.
We have a single default.rgw.buckets.data where all data is being stored the rest of the pools are adminitrastive and internal to cephs metadata and book keeping.
PGs per osd (what is a reasonable default anyway???)
The documentation would have us use this calculation to determine our pg count per osd:
(osd * 100)
----------- = pgs UP to nearest power of 2
replica count
It is stated that to round up is optimal. So with our current setup it would be:
(4 * 100)
----------- = (200 to the nearest power of 2) 256
2
osd.1 ~= 256
osd.2 ~= 256
osd.3 ~= 256
osd.4 ~= 256
This is the recommended max number of pgs per osd. So... what do you actually have currently? And why isn't it working? And if you set a
'reasonable default' and understand the above WHY ISN'T IT WORKING!!! >=[
Likely, a few reasons. We have to understand what those 'reasonable defaults' above actually mean, how ceph applies them and to where. One might misunderstand from the above that I could create a new pool like so:
ceph osd pool create <pool> 256 256
or I might even think I could play it safe and follow the documentation which states that (128 pgs for < 5 osds) can use:
ceph osd pool create <pool> 128 128
This is wrong, flat out. Because it in no way explains the relationship or balance between what ceph is actaully doing with these numbers
technically the correct answer is:
ceph osd pool create <pool> 32 32
And let me explain why:
If like me you provisioned your cluster with those 'reasonable defaults' (128 pgs for < 5 osds) as soon as you tried to do anything with rados it created a whole bunch of pools and your cluster spazzed out.
The reason is because I misunderstood the relationship between everything mentioned above.
pools: 10 (created by rados)
pgs per pool: 128 (recommended in docs)
osds: 4 (2 per site)
10 * 128 / 4 = 320 pgs per osd
This ~320 could be a number of pgs per osd on my cluster. But ceph might distribute these differently. Which is exactly what's happening and
is way over the 256 max per osd stated above. My cluster's HEALTH WARN is HEALTH_WARN too many PGs per OSD (368 > max 300).
Using this command we're able to see better the relationship between the numbers:
pool :17 18 19 20 21 22 14 23 15 24 16 | SUM
------------------------------------------------< - *total pgs per osd*
osd.0 35 36 35 29 31 27 30 36 32 27 28 | 361
osd.1 29 28 29 35 33 37 34 28 32 37 36 | 375
osd.2 27 33 31 27 33 35 35 34 36 32 36 | 376
osd.3 37 31 33 37 31 29 29 30 28 32 28 | 360
-------------------------------------------------< - *total pgs per pool*
SUM :128 128 128 128 128 128 128 128 128 128 128
There's a direct correlation between the number of pools you have and the number of placement groups that are assigned to them.
I have 11 pools in the snippet above and they each have 128 pgs and that's too many!! My reasonable defaults are 64! So what happened??
I was misunderstandning how the 'reasonable defaults' were being used. When I set my default to 64, you can see ceph has taking my crush map into account where
I have a failure domain between site a and site b. Ceph has to ensure that everything that's on site a is at least accessible on site b.
WRONG
site a
osd.0
osd.1 TOTAL of ~ 64pgs
site b
osd.2
osd.3 TOTAL of ~ 64pgs
We needed a grand total of 64 pgs per pool so our reasonable defaults should've actually been set to 32 from the start!
If we use ceph osd pool create <pool> 32 32 what this amounts to is that the relationship between our pgs per pool and pgs per osd with those 'reasonable defaults' and our recommened max pgs per osd start to make sense:
So you broke your cluster ^_^
Don't worry we're going to fix it. The procedure here I'm afraid might vary in risk and time depending on how big your cluster. But the only way
to get around altering this is to add more storage, so that the placement groups can redistribute over a larger surface area. OR we have to move everything over to
newly created pools.
I'll show an example of moving the default.rgw.buckets.data pool:
old_pool=default.rgw.buckets.data
new_pool=new.default.rgw.buckets.data
create a new pool, with the correct pg count:
ceph osd pool create $new_pool 32
copy the contents of the old pool the new pool:
rados cppool $old_pool $new_pool
remove the old pool:
ceph osd pool delete $old_pool $old_pool --yes-i-really-really-mean-it
rename the new pool to 'default.rgw.buckets.data'
ceph osd pool rename $new_pool $old_pool
Now it might be a safe bet to restart your radosgws.
FINALLY CORRECT
site a
osd.0
osd.1 TOTAL of ~ 32pgs
site b
osd.2
osd.3 TOTAL of ~ 32pgs
As you can see my pool numbers have incremented since they are added by pool id and are new copies. And our total pgs per osd is way under the ~256 which gives us room to add custom pools if required.
pool : 26 35 27 36 28 29 30 31 32 33 34 | SUM
-----------------------------------------------
osd.0 15 18 16 17 17 15 15 15 16 13 16 | 173
osd.1 17 14 16 15 15 17 17 17 16 19 16 | 179
osd.2 17 14 16 18 12 17 18 14 16 14 13 | 169
osd.3 15 18 16 14 20 15 14 18 16 18 19 | 183
-----------------------------------------------
SUM : 64 64 64 64 64 64 64 64 64 64 64
Now you should test your ceph cluster with whatever is at your disposal. Personally I've written a bunch of python over boto that tests the infrastructure and return buckets stats and metadata rather quickly. They have ensured to me that the cluster is back to working order without any of the issues it suffered from previously. Good luck!
Fixing pool default.rgw.buckets.data has many more objects per pg than average (too few pgs?) once and for all
This quite literally means, you need to increase the pg and pgp num of your pool. So... do it. With everything mentioned above in mind. When you do this however note that the cluster will start backfilling and you can watch this process %: watch ceph -s in another terminal window or screen.
ceph osd pool set default.rgw.buckets.data pg_num 128
ceph osd pool set default.rgw.buckets.data pgp_num 128
Armed with the knowledge and confidence in the system provided in the above segment we can clearly understand the relationship and the influence of such a change on the cluster.
pool : 35 26 27 36 28 29 30 31 32 33 34 | SUM
----------------------------------------------
osd.0 18 64 16 17 17 15 15 15 16 13 16 | 222
osd.1 14 64 16 15 15 17 17 17 16 19 16 | 226
osd.2 14 66 16 18 12 17 18 14 16 14 13 | 218
osd.3 18 62 16 14 20 15 14 18 16 18 19 | 230
-----------------------------------------------
SUM : 64 256 64 64 64 64 64 64 64 64 64
Can you guess which pool id is default.rgw.buckets.data? haha ^_^
In Ceph Nautilus (v14 or later), you can turn on "PG Autotuning". See this documentation and this blog entry for more information.
I accidentally created pools with live data that I could not migrate to repair the PGs. It took some days to recover, but the PGs were optimally adjusted with zero problems.
I am trying load testing here. My backend is in Ruby(2.2) on Rails(3).
I read many pages about how to work with Ab testing.
Here is what I have tried:
ab -n 100 -c 30 url
Result:
This is ApacheBench, Version 2.3 <$Revision: 1554214 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 52.74.130.35 (be patient).....done
Server Software: nginx/1.6.2
Server Hostname: 52.74.130.35
Server Port: 80
Document Path: url
Document Length: 1372 bytes
Concurrency Level: 3
Time taken for tests: 10.032 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 181600 bytes
HTML transferred: 137200 bytes
Requests per second: 9.97 [#/sec] (mean)
Time per request: 300.963 [ms] (mean)
Time per request: 100.321 [ms] (mean, across all concurrent requests)
Transfer rate: 17.68 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 9 25.0 5 227
Processing: 176 289 136.5 257 1134
Waiting: 175 275 77.9 256 600
Total: 180 298 139.2 264 1143
Percentage of the requests served within a certain time (ms)
50% 264
66% 285
75% 293
80% 312
90% 361
95% 587
98% 1043
99% 1143
Which seams to be working perfectly. But my problem is I want to test many API's, not just one. So I have to write a script in which I write all the Api's with particular probabilities(weights) and load test on them.
I know how its possible with Locust, but locust does not support nested json to be passed as parameters.
Can somebody help with this.
Also let me know if there is any problem/ambiguity in the question itself.
i am not able to render or capture video on ios.
After successful SDP negtiation i tried to add video call for existing audio call, in on_call_media_state callback i observed that the media is not active for video.
When i hung up the call i get the following log which shows #1 video H263-1998, inactive, peer=10.11.201.147:50858.
According to Siphon some are able to get the video stream on ios devices.
Any help would be appreciated
3-11-15 14:59:39.075 ipjsua[220:6007] 14:59:39.075 pjsua_app.c .....Call 1 is DISCONNECTED [reason=200 (Normal call clearing)]
2013-11-15 14:59:39.093 ipjsua[220:6007] 14:59:39.093 pjsua_app.c .....
2013-11-15 14:59:39.097 ipjsua[220:6007] [DISCONNCTD] To: "102" <sip:102#10.11.201.147>;tag=bf76b652
Call time: 00h:04m:04s, 1st res in 121 ms, conn in 674ms
#0 audio speex #16kHz, sendrecv, peer=10.11.201.147:22268
SRTP status: Not active Crypto-suite: (null)
RX pt=100, last update:00h:00m:00.627s ago
total 12.1Kpkt 1.29MB (1.78MB +IP hdr) #avg=42.2Kbps/58.2Kbps
pkt loss=4 (0.0%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)
(msec) min avg max last dev
loss period: 20.000 20.000 20.000 20.000 0.000
jitter : 0.000 6.258 32.187 14.500 3.978
TX pt=100, ptime=20, last update:00h:00m:02.013s ago
total 8.3Kpkt 249.0KB (581.7KB +IP hdr) #avg=8.1Kbps/19.0Kbps
pkt loss=152 (1.8%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 20.000 49.836 140.000 120.000 25.816
jitter : 5.500 20.248 75.750 33.250 14.885
RTT msec : 5.966 50.438 146.325 131.000 33.555
#1 video H263-1998, inactive, peer=10.11.201.147:50858
SRTP status: Not active Crypto-suite: (null)
RX last update:00h:01m:30.404s ago
total 12pkt 48B (528B +IP hdr) #avg=2bps/22bps
pkt loss=0 (0.0%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : -0.001 0.000 0.000 0.000 0.000
TX last update:00h:01m:03.332s ago
total 0pkt 0B (0B +IP hdr) #avg=0bps/0bps
pkt loss=1 (100.0%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 0.000 0.000 0.000 0.000 0.000
RTT msec : 0.000 0.000 0.000 0.000 0.000
#2 video H263-1998, inactive, peer=10.11.201.147:22264
SRTP status: Not active Crypto-suite: (null)
RX last update:00h:01m:39.059s ago
total 15pkt 60B (660B +IP hdr) #avg=2bps/27bps
pkt loss=0 (0.0%), discrd=2 (13.3%), dup=2 (13.3%), reord=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : -0.001 0.000 0.000 0.000 0.000
TX last update:00h:01m:08.467s ago
total 0pkt 0B (0B +IP hdr) #avg=0bps/0bps
pkt loss=1 (100.0%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 0.000 0.000 0.000 0.000 0.000
RTT msec : 0.000 0.000 0.000 0.000 0.000
2013-11-15 14:59:39.214 ipjsua[220:6007] 14:59:39.214 pjsua_media.c .....Call 1: deinitializing media..
2013-11-15 14:59:39.231 ipjsua[220:6007] 14:59:39.231 pjsua_media.c .......Media stream call01:0 is destroyed
2013-11-15 14:59:39.253 ipjsua[220:6007] 14:59:39.253 pjsua_vid.c .......Stopping video stream..
2013-11-15 14:59:39.259 ipjsua[220:6007] 14:59:39.259 pjsua_media.c .......Media stream call01:1 is destroyed
2013-11-15 14:59:39.264 ipjsua[220:6007] 14:59:39.264 pjsua_vid.c .......Stopping video stream..
2013-11-15 14:59:39.276 ipjsua[220:6007] 14:59:39.276 pjsua_media.c .......Media stream call01:2 is destroyed
2013-11-15 14:59:40.232 ipjsua[220:6007] 14:59:40.231 pjsua_aud.c Closing sound device after idle for 1 second(s)
2013-11-15 14:59:40.234 ipjsua[220:6007] 14:59:40.234 pjsua_app.c .Turning sound device OFF
2013-11-15 14:59:40.253 ipjsua[220:6007] 14:59:40.252 pjsua_aud.c .Closing iPhone IO device sound playback device and iPhone IO device sound capture device
2013-11-15 14:59:40.415 ipjsua[220:6007] 14:59:40.415 coreaudio_dev. .core audio stream stopped
2013-11-15 15:00:33.609 ipjsua[220:6007] 15:00:33.608 pjsua_core.c .RX 719 bytes Request msg SUBSCRIBE/cseq=52 (rdata0xa41a14) from UDP 10.11.201.147:5060:
SUBSCRIBE sip:101#10.11.208.114:5060;ob SIP/2.0
2013-11-15 15:19:54.347 ipjsua[220:6007] 15:19:54.347 pjsua_app.c .....Call 2 is DISCONNECTED [reason=200 (Normal call clearing)]
PJSIP on iOS does not currently implement Video Media.
The data sheet states which OSs video is implemented for:
Video Media
Platforms:
Windows,
Linux,
Mac
Codecs:
H.263-1998 (ffmpeg),
H.264 (ffmpeg and x264)
Capture devices:
colorbar (all platforms)
DirectShow (Windows)
Video4Linux2 (Linux)
QuickTime (Mac OS X)
Rendering devices:
SDL (Windows, Linux, and Mac OS X)
DirectShow (Windows)
http://trac.pjsip.org/repos/wiki/PJSIP-Datasheet
Further, the video user guide states that mobile OSs are not yet supported:
Video is available on PJSIP version 2.0 and later. Only desktop platforms are supported, mobile devices such as iOS are not yet supported.
http://trac.pjsip.org/repos/wiki/Video_Users_Guide