<html tabindex="-1" style="-ms-scrollbar-base-color: rgb(0, 0, 0); -ms-scrollbar-face-color: rgb(240, 240, 240); -ms-scrollbar-3dlight-color: rgb(227, 227, 227); -ms-scrollbar-shadow-color: rgb(160, 160, 160); -ms-scrollbar-highlight-color: rgb(255, 255, 255); -ms-scrollbar-darkshadow-color: rgb(105, 105, 105); -ms-scrollbar-arrow-color: rgb(0, 0, 0);">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta http-equiv="X-UA-Compatible" content="IE=10">
<meta name="GENERATOR" content="MSHTML 11.00.9600.17107">
<style id="owaParaStyle" style="display: none;">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body tabindex="0" style="" dir="ltr" aria-label="Message body" fPStyle="1">
<div name="divtagdefaultwrapper" id="divtagdefaultwrapper" style="font-family: Calibri,Arial,Helvetica,sans-serif; font-size: 12pt; color: #000000; margin: 0">
<p class="owaPara">>It wasn't clear to me - from your original message - what port numbers you are choosing. For each stream, you *must* use an even numbered port number for RTCP, and that port number +1 (i.e., odd-numbered) for RTCP. Also, you *should* use
different port numbers for each stream.</p>
<p class="owaPara">>E.g., for stream 1, you could use 8000 for RTP, and 8001 for RTCP. For stream 2, you could use 8002 for RTP, and 8003 for RTCP. Etc.</p>
<p class="owaPara">>Because you are (correctly) using a different IP multicast address for each stream, it shouldn't matter, in principle, if you use different port numbers for each stream. In practice, however, it might matter (and it does matter in some
versions of Linux), so that's what I recommend.<br>
</p>
<p class="owaPara">Currently I use 8552, 8554, 8556, 8558 for RTSP ports. At my first implementation all RTP port was 18888 and RTCP was 18887, but after I found the problem, I changed this first, as a temporally solution not I calculate RTP port = RTSP port
- 1000 and RTCP port = RTSP - 999.</p>
<p class="owaPara"> </p>
<p class="owaPara">>But apart from that, I don't see anything in our software that could be causing your problem. But you clearly are running into a resource limit somewhere. Is your CPU usage at (or close to) 100% when you start having problems with multiple
streams? If so, then you should be able to figure out - using profiling software - where most of the CPU usage is occurring. If, however, the resource limit that you're hitting is *not* your CPU, and it's not your network, then it has to be file I/O, or
something else in your OS.</p>
<p class="owaPara">>Finally, I assume that you're not trying to run multiple copies of *VLC" on the same computer. (Someone reported a similar issue about a month ago, but it turned out that their real problem was that they were trying to run multiple copies
of VLC on the same computer.) </p>
<p class="owaPara"> </p>
<p class="owaPara">Yes, I also think, that I use too much resource somewhere, but I don't know which.</p>
<p class="owaPara">Network bandwidth shouldn't be problem (2500KB/s).</p>
<p class="owaPara">CPU usage is lower than 20% (together with receiving part) also shouldn't be problem.</p>
<p class="owaPara">For file I/O I use the general FileSource DirectShow filter, which has to work well. (I also use different video files to surly prevent this problem.)</p>
<p class="owaPara"> </p>
<p class="owaPara">Until now in my test I used VLC, because I thought, that is stable. But we also have a RTSP Source filter which also using live555 solution, and I repeated my test using that to accept the stream, but I experienced the same problem. Note
that if I receive the stream on another computer, the same problem happens on the streaming computer. Also note that after I seemingly lost my network connection (Skype disconnect and I can't open anything in browser), streaming doesn't stop immediately. This
suggests some king of network resource problem, but not the bandwidth, because resource monitor shows under 10% usage.</p>
</div>
</body>
</html>