<div dir="ltr">Thanks for the response. <br><br>Well, the rabbit hole got deeper as I actually hard coded (as a hack, obviously) the SR reports to always report 0 for the octet and packet count. That did nothing. So my theory was proven to be incorrect. I'm going to update the server code and try that. <br><br>We're talking with clients now and seeing if we can either get them to update their phones to a later version of Android or use different phones. At a certain point we have to conclude it's probably the fact the phones are kind of crappy (and they are). <br><br>Thanks for your help. If I stumble across something I'll let you know and respond on this thread. <br><br>Cheers mate. </div><br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 20, 2016 at 3:46 PM Ross Finlayson <<a href="mailto:finlayson@live555.com">finlayson@live555.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One more thing: As always, make sure that you’re using the latest version of the code (2016.04.01); see<br>
<a href="http://live555.com/liveMedia/faq.html#latest-version" rel="noreferrer" target="_blank">http://live555.com/liveMedia/faq.html#latest-version</a><br>
<br>
I’m at a loss to understand what could be causing this problem; it definitely appears to be a bug of some sort in your ‘Android Phone’ media player. But, as you noted, the only difference - from the client’s point of view - between connecting first and connecting second (when “reuseFirstSource” is True in the server) is that the second client will see RTCP “SR” reports that begin with non-zero packet count and octet count fields. But it’s hard to see how this could be causing a problem with your media player (and it’s certainly not a ‘bug’ of any sort in our server code).<br>
<br>
But just to test this out, please run our<br>
testH264VideoStreamer<br>
demo application (in the “testProgs” directory). This program reads from a file named “test.264”; for this, you can download and use this file<br>
<a href="http://www.live555.com/liveMedia/public/264/test.264" rel="noreferrer" target="_blank">http://www.live555.com/liveMedia/public/264/test.264</a><br>
<br>
Then, run your ‘Android Phone’ media player to try to play this stream. Because “testH264VideoStreamer” streams via IP multicast, your media player will need to be running on the same LAN as the server application (i.e., via WiFi, not a cellular data network). But if your media player is working correctly, it should play the (H.264 video-only) stream properly, regardless of when it starts playing the stream, and regardless of how many other clients have already asked to play the stream.<br>
<br>
Note that because the server, in this example, is streaming a single multicast stream to a potentially arbitrary number of (IP multicast) clients, the RTCP “SR” reports will all contain non-zero packet count and octet count fields.<br>
<br>
<br>
Ross Finlayson<br>
Live Networks, Inc.<br>
<a href="http://www.live555.com/" rel="noreferrer" target="_blank">http://www.live555.com/</a><br>
<br>
<br>
_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com" target="_blank">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" rel="noreferrer" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
</blockquote></div>