[Live-devel] Logging or debug info
Jan Ekholm
jan.ekholm at d-pointer.com
Tue May 6 11:47:01 PDT 2014
On 6 maj 2014, at 20:40, Ross Finlayson <finlayson at live555.com> wrote:
>> Testing with:
>>
>> ./testRTSPClient rtsp://192.168.1.12:8554/camera0
>>
>> it seems to work ok until the 65 second timeout occurs on the server side. Perhaps it does not handle the
>> needed RTSP conversation? Same happens with ./openRTSP. I see from my server logs that the camera
>> I stream gets deallocated. I have done nothing custom on the Live555 side for the low level RTSP handling,
>> so I assume the clients don't do the needed talking. Live555 says as much too after enabling the DEBUG
>> variable:
>>
>> RTSP client session (id "2FBE732F", stream name "camera0") has timed out (due to inactivity)
>
> The problem here is that your server is not receiving the frequent RTCP "RR" reports that the client (both "testRTSPClient" and "openRTSP") is sending. Because you say that your server is built using the LIVE555 library, this surprises me.
It's all a bit random, as some clients can run hours, like VLC. It all seems to depend on how many clients
are connected. A single client and there are no problems ever. As soon as there are more clients or
the same client crashes/killed/exits and reconnects the problems start. At that point own libav based
client will freeze sooner or later.
> Does your server stream via multicast - i.e., using a "PassiveServerMediaSubsession", like the "test*Streamer" demo applications in the "testProgs" directory? If so, then your server *must* create a "RTCPInstance" object along with each "RTPSink" object (as you can see in the "test*Streamer" example code).
No multicast yet, but that is planned. I have seen and initially used code based on those examples, but then
I at least temporarily migrated to use OnDemandServerMediaSubsession.
> Or does your server stream via unicast - i.e., using a (subclass of) "OnDemandServerMediaSubsession" - as demonstrated by the "testOnDemandRTSPServer" demo application (or by the "LIVE555 Media Server")? If so, then I can't see how you could be having this problem, because "OnDemandServerMediaSubsession" automatically creates "RTCPInstance" objects.
Yes, I use that. My subclass mostly does the getAuxSDPLine() handling for H264 as well as trivial versions
of createNewStreamSource() and createNewRTPSink().
>
>> I also now see that the server always streams over TCP
>
> No, you're mistaken about this (unless you've modified the "RTSPServer.cpp" code, in which case you can't expect any support on this mailing list). "testRTSPClient" (unless modified) always requests RTP/RTCP-over-UDP streaming, as does "openRTSP" (unless you explicitly give it the "-t" option).
In my code I use an unmodified instance of RTSPServer (apart from the now added DEBUG flag). It gets
a few different sessions based on subclassed OnDemandServerMediaSubsession and ProxyServerMediaSession.
They are not modified either. The current stream I test with is streaming H264, but also another using MJPEG
has the same issues
This is what my server says (or the Live555 code through DEBUG=1) when I run testRTSPClient when there are
no other clients and no old sessions timing out:
accept()ed connection from 192.168.1.12
RTSPClientConnection[0x10300e000]::handleRequestBytes() read 156 new bytes:DESCRIBE rtsp://192.168.1.12:8554/camera0 RTSP/1.0
CSeq: 2
User-Agent: ./testRTSPClient (LIVE555 Streaming Media v2014.03.25)
Accept: application/sdp
parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "camera0", CSeq "2", Content-Length 0, with 0 bytes following the message.
sending response: RTSP/1.0 200 OK
CSeq: 2
Date: Tue, May 06 2014 18:13:57 GMT
Content-Base: rtsp://192.168.1.12:8554/camera0/
Content-Type: application/sdp
Content-Length: 521
v=0
o=- 1399371554452606 1 IN IP4 192.168.1.12
s=Local H264 camera
i=Camera
t=0 0
a=tool:LIVE555 Streaming Media v2014.03.25
a=type:broadcast
a=control:*
a=source-filter: incl IN IP4 * 192.168.1.12
a=rtcp-unicast: reflection
a=range:npt=0-
a=x-qt-text-nam:Local H264 camera
a=x-qt-text-inf:Camera
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:200
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=42C01F;sprop-parameter-sets=Z0LAH9kAUAW6EAAAAwAQAAADAyjxgySA,aMuDyyA=
a=control:track1
RTSPClientConnection[0x10300e000]::handleRequestBytes() read 187 new bytes:SETUP rtsp://192.168.1.12:8554/camera0/track1 RTSP/1.0
CSeq: 3
User-Agent: ./testRTSPClient (LIVE555 Streaming Media v2014.03.25)
Transport: RTP/AVP;unicast;client_port=65142-65143
parseRTSPRequestString() succeeded, returning cmdName "SETUP", urlPreSuffix "camera0", urlSuffix "track1", CSeq "3", Content-Length 0, with 0 bytes following the message.
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: profile Constrained Baseline, level 3.1
sending response: RTSP/1.0 200 OK
CSeq: 3
Date: Tue, May 06 2014 18:14:00 GMT
Transport: RTP/AVP;unicast;destination=192.168.1.12;source=192.168.1.12;client_port=65142-65143;server_port=6970-6971
Session: 90DD8B79;timeout=65
RTSPClientConnection[0x10300e000]::handleRequestBytes() read 166 new bytes:PLAY rtsp://192.168.1.12:8554/camera0/ RTSP/1.0
CSeq: 4
User-Agent: ./testRTSPClient (LIVE555 Streaming Media v2014.03.25)
Session: 90DD8B79
Range: npt=0.000-
parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "camera0", urlSuffix "", CSeq "4", Content-Length 0, with 0 bytes following the message.
sending response: RTSP/1.0 200 OK
CSeq: 4
Date: Tue, May 06 2014 18:14:01 GMT
Range: npt=0.000-
Session: 90DD8B79
RTP-Info: url=rtsp://192.168.1.12:8554/camera0/track1;seq=5372;rtptime=2132557593
RTSP client session (id "90DD8B79", stream name "camera0") has timed out (due to inactivity)
When that happens, testRTSP has shown a long line of:
Stream "rtsp://192.168.1.12:8554/camera0/"; video/H264: Received 2385 bytes. Presentation time: 1399400105.931199
and then just freezes.
UPDATE:
I looked through my own code again after writing this looking for clues. What does the "isSSM" flag really do here:
class ServerMediaSession: public Medium {
public:
static ServerMediaSession* createNew(UsageEnvironment& env,
char const* streamName = NULL,
char const* info = NULL,
char const* description = NULL,
Boolean isSSM = False,
char const* miscSDPLines = NULL);
...
The code I based my code on was for PassiveServerMediaSubsession which uses SSM. I set that flag
to False now and that makes testRTSPClient work longer than 65 s. Still my own client gets issues as
soon as there are more clients connected.
Now I also seem to get from the testRTSPClient:
RTSP client session (id "133E19DE", stream name "camera0"): Liveness indication
RTSP client session (id "133E19DE", stream name "camera0"): Liveness indication
after few seconds, which I did not get when isSSM=True. My own client does not seem
to send those, but instead I get these every 10 seconds or so:
parseRTSPRequestString() succeeded, returning cmdName "GET_PARAMETER", urlPreSuffix "camera0", urlSuffix "", CSeq "10", Content-Length 0, with 0 bytes following the message.
sending response: RTSP/1.0 200 OK
CSeq: 10
Date: Tue, May 06 2014 18:44:53 GMT
Session: 6A8077BD
Content-Length: 10
This is quite complicated... I'm sorry for troubling you with this, but I'm grasping at straws
trying to get this to work.
Best regards,
Jan Ekholm
More information about the live-devel
mailing list