One more thing: As always, make sure that you’re using the latest version of
the code (2016.04.01); see
http://live555.com/liveMedia/faq.html#latest-version
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).
But just to test this out, please run our
testH264VideoStreamer
demo application (in the “testProgs” directory). This program reads from a
file named “test.264”; for this, you can download and use this file
http://www.live555.com/liveMedia/public/264/test.264
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.
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.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
