[Live-devel] Problem in sending PAUSE and then PLAY request in openrtsp

Andrey Kaminsky and at faonet.com
Tue Jul 24 12:09:23 PDT 2007


On Tue, 2007-07-24 at 12:54 -0500, Ross Finlayson wrote:
> >On Tue, 2007-07-24 at 05:19 -0500, Ross Finlayson wrote:
> >>  > We are using openRTSP Client to receive mpeg2 streams. When we call
> >>  > PAUSE and then PLAY request during streaming then
> >>  >  we observed functiongetResponse1() is getting called from two
> >>  > places simultaneously
> >>
> >  >
> >>  No. Remember that the code is single-threaded.  It is not possible for
> >>  "getResponse1()" - or any other function - to be called from two
> >>  places 'simultaneously'.
> >>
> >I found the same things. live.2007.04.24a
> >
> >in file RTSPClient.cpp: function
> >
> >Boolean RTSPClient::playMediaSession(MediaSession& session,
> >                                      float start, float end, float
> >scale) {
> >................
> >line 1096
> >     if (fTCPStreamIdCount == 0) { // we're not receiving RTP-over-TCP
> >       // Arrange to handle incoming requests sent by the server
> >
> >envir().taskScheduler().turnOnBackgroundReadHandling(fInputSocketNum,
> >
> >(TaskScheduler::BackgroundHandlerProc*)&incomingRequestHandler, this);
> >     }
> >
> >If you comment out this code block, than you can always resume from
> >  pause. Otherwise this is like a russian roulette :-).
> >
> >getResponse -> getResponse1 -> (pause/resume okey)
> >OR
> >incomingRequestHandler -> incomingRequestHandler1 -> getResponse1 ->
> >you are blocked in select
> 
>  From what I can tell, the second case should not be happening, 
> because the "pauseMediaS(ubs)ession()"  function does synchronous 
> I/O, and does not enter the event loop.  ("incomingRequestHandler()" 
> is called only from within the event loop.)   I.e., if you call 
> "pauseMediaS(ubs)ession()", you'll sent the "PAUSE" command, and then 
> wait for and read the subsequent response - without any problem.

Ok, Ross. You are designer, and you know this code much better.

We are trying to implement udp streaming server (up to 16 jpeg video
 streams per client) and client application to recieve and visualise
 this streams. And I had problem with pauseMediaSubsession and resume
paused subsessions (playMediaSubsession) with client subsessions lockups
sometimes in pauseMediaSubsession call, sometimes in playMediaSubsession
 call (to resume paused subsessions), sometimes without subsessions
 lockups. And I had tracked problem to this  piece of code. After I had
 commented out this block, I had 100% success with this functions. 
May be this is due my incorrect library use. But this work for me
 without any problem. live555 is live now!!!
Thanx for Your work.

And additional patches against live.2007.04.24a, to prevent segfaults.

diff -u JPEGVideoRTPSink.cpp /usr/src/RPM/BUILD/live/liveMedia/
--- JPEGVideoRTPSink.cpp        2007-04-24 12:38:22.000000000 +0300
+++ /usr/src/RPM/BUILD/live/liveMedia/JPEGVideoRTPSink.cpp
2007-04-26 15:54:47.000000000 +0300
@@ -60,13 +60,15 @@
   mainJPEGHeader[1] = fragmentationOffset >> 16;
   mainJPEGHeader[2] = fragmentationOffset >> 8;
   mainJPEGHeader[3] = fragmentationOffset;
-  mainJPEGHeader[4] = source->type();
-  mainJPEGHeader[5] = source->qFactor();
-  mainJPEGHeader[6] = source->width();
-  mainJPEGHeader[7] = source->height();
+  if (source != NULL) {
+    mainJPEGHeader[4] = source->type();
+    mainJPEGHeader[5] = source->qFactor();
+    mainJPEGHeader[6] = source->width();
+    mainJPEGHeader[7] = source->height();
+  }
   setSpecialHeaderBytes(mainJPEGHeader, sizeof mainJPEGHeader);

-  if (fragmentationOffset == 0 && source->qFactor() >= 128) {
+  if (source != NULL && fragmentationOffset == 0 && source->qFactor()
>= 128) {
     // There is also a Quantization Header:
     u_int8_t precision;
     u_int16_t length;
@@ -108,7 +110,7 @@

   unsigned headerSize = 8; // by default

-  if (curFragmentationOffset() == 0 && source->qFactor() >= 128) {
+  if (source != NULL && curFragmentationOffset() == 0 &&
source->qFactor() >= 128) {
     // There is also a Quantization Header:
     u_int8_t dummy;
     u_int16_t quantizationTablesSize;


Regards
Andrey Kaminsky





More information about the live-devel mailing list