[Live-devel] strange behavior with Android 5.0 lollipop media player

[Ben Rush]

Yes, my apologies for being unclear. I can see now how what I said might be
difficult to understand. I will try to do better and be a bit more
pedantic.

I'm on Windows and I've built a RTSP server that connects to a camera and
serves both audio and video using the Live555 server libraries. I used some
scripts to build the libraries for Windows and am using them from Visual
Studio 2015. From the highest level, this is how I have things starting up
from within the main() of the application server program (and so when I say
"spin up", I mean this application gets executed):

        TaskScheduler* taskSchedular = BasicTaskScheduler::createNew();
        BasicUsageEnvironment* usageEnvironment =
BasicUsageEnvironment::createNew(*taskSchedular);
        RTSPServer* rtspServer = RTSPServer::createNew(*usageEnvironment,
StreamingOptions::PortNumber, NULL);
        if (rtspServer == NULL)
        {
            *usageEnvironment << "Failed to create rtsp server ::" <<
usageEnvironment->getResultMsg() << "\n";
            exit(1);
        }

        ServerMediaSession* sms =
ServerMediaSession::createNew(*usageEnvironment,
            StreamingOptions::StreamName.c_str(),
StreamingOptions::StreamName.c_str(), "Live H264 Stream");

        H264LiveServerMediaSession *liveSubSession =
H264LiveServerMediaSession::createNew(*usageEnvironment, true);
        sms->addSubsession(liveSubSession);
        if (StreamingOptions::DoAudio)
        {
            WindowsAudioMediaSession* audioSession =
WindowsAudioMediaSession::createNew(*usageEnvironment, true);
            sms->addSubsession(audioSession);
        }

So as you can see, a fairly straightforward implementation. And it has
worked very well up until recently.

We have clients that are connecting to this server using Android phones;
more specifically Android 5.0 Lollipop phones. They connect using the
standard "MediaPlayer" control that is part of the Android SDK. So, a
totally "stock" player. There are no proxies, they simply make a request
for rtsp://<address>:<port>/<streamName>. Again, pretty straightforward.

However, there is something peculiar about these particular Android phones
in that if another client is already connected to the above streaming
server and streaming content (say I connect to it via VLC), then NO PHONE
who connects after is able to stream any content (audio or video). Other
types of players (VLC, etc.) are able to connect and stream just fine; the
phones, however, cannot. The phone indeed connects as I'm able to see RTP
traffic streaming to the phone from the server; yet nothing plays (in fact,
the entire RTCP/RTSP handshake looks normal).

Under normal circumstances we'd think this was totally an issue with the
player (and it may still be), however IF the phone is the ONLY client to
connect, then it streams content just fine. IF I set the server to NOT
reuse sessions above (in other words, if I modify the above code to have
FALSE as part of it second parameter of
H264LiveServerMediaSession::createNew(*usageEnvironment, FALSE)), then
everything streams fine, even if other clients are already connected. So
setting the reuse connections parameter to false does, indeed, "fix" the
problem (however, I've read that isn't necessarily a great solution as it
can cause performance issues).

So to be more precise:

Works:

1) Above server launches,
2) Phone connects as the ONLY client,
3) Phone will stream content,

OR

1) Above server launches,
2) H264LiveServerMediaSession::createNew(*usageEnvironment, false); //
false, not true
3) Phone can connect and stream just fine regardless of other concurrent
connections

Doesn't work:

1) Above server launches,
2) H264LiveServerMediaSession::createNew(*usageEnvironment, true)
3) Connect to the server using VLC or any of a dozen other players we've
tested,
4) Phone will connect to server,
5) Phone won't stream the content.

Digging into the details, the only peculiarity I have been able to find is
that, as I mentioned previously, when reusing the existing connections, the
streaming server appears to be returning Sender's Packet count of >0 to a
newly connected client IF a separate client has already been connected and
streaming (this as part of the first RTCP Sender Report). If the phone is
the only client to connect, the Sender's Packet count = 0.This is the ONLY
major difference I'm able to note when watching a phone connecting and
attempting to stream as the only client, or as a subsequent client. And so
the only theory I have is that these players are somehow either A) not
abiding by the rules and getting confused because the Sender's packet count
> 0 or, and this seems far less likely, there's a bug in the underlying
server code that is somehow serving a Sender's Packet count > 0 for
subsequent clients that connect IF the reuse existing connection flag
(above) is set to False.

Again, if setting the second parameter here to false:
H264LiveServerMediaSession::createNew(*usageEnvironment,
FALSE) didn't "fix" the issue, or if the Android player was never able to
stream at all, I'd just assume it was completely an issue with the player.
But since these things do alter the behavior of the client, I'm wondering
if it's maybe an incompatibility and, if so, I'm wondering if there are any
thoughts on what I can do to better support these clients.

Thanks again for your time.



On Tue, Apr 19, 2016 at 6:18 PM Ross Finlayson <finlayson at live555.com>
wrote:

> Sorry, but I’m having a hard time understanding your question, and, in
> particular, how it relates to the “LIVE555 Streaming Media” software.
> Could you please explain *specifically* what your system looks like (i.e.,
> server(s), client(s), proxy/proxies if any, etc.), and how, *specifically*,
> the “LIVE555 Streaming Media” software is involved?
>
> Please understand that “LIVE555” isn’t a single thing, and phrases like
> “spin up LIVE555” are completely meaningless.  Our software consists of
> RTSP/RTP/RTCP client software, RTSP/RTP/RTCP server software, RTSP proxy
> software, various demo applications (“testProgs”), a proxy server
> application, and a prebuilt media server application, etc.  In order to be
> understood, you need to explain specifically which parts of all of this
> software you are using, and how.
>
>
> 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/20160420/084793e0/attachment.html>