Chang, Dashan | 27 Feb 16:16 2015

Bug report of Live555ProxyServer

Hi,

 

My name is Dashan Chang and I am a developer with Kastle Systems. Recently I am exploring feasibility of using your Live555ProxyServer to stream out a live view of a set of cameras to VLC player via its Open Network Stream. After I switch back and forth from one camera to another, VLC no longer shows up the live view unless the Live555ProxyServer is killed and re-launched. This is very consistent.

 

Attached is the log file of the proxy server’s console output.

 

Can you see what and where the server starts to stop working from the log file? Is there any indicator in the log file indicating that the server needs to be relaunched?

 

I hope my report can help this server to be further refined and improved into a wonderful product.  I have a pretty good and practical environment that fits very well to set Live555ProxyServer.

 

Please let me know if you need any further info and tests.

 

Thank You and Best Regards!
Dashan

 

 

Attachment (Live555ProxyServer.log): application/octet-stream, 157 KiB
_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Jooil Chang | 27 Feb 07:13 2015

[Live_devel] RTCP handling in RTSP client

Hi, I have some questions.

In my setup, my RTSP client for VOD uses another RTSP library(CURL), and RTSP server is live555.

(Due to the some reasons, I cannot use openRTSP for the client)

Because CURL only handles RTSP commands, I need to implement RTP receiver part myself.

 

Question 1) 

I have read live555 FAQ that says, to synchronize separate streams like audio and video, RTCP is needed. If so, should I also implement RTCP handling in my client?

 

Question 2) 

When I stream TS file with audio and video from VLC, its SDP shows audio and video media description separately.

But when I stream the same file from live555 media server, SDP only shows video media,

in this case I can hear audio, and when I save output with -v option(video only) in openRTSP, 

output file also has the audio track.

Why does this happen? 

In this case is RTCP also needed?

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
夏江龙 | 26 Feb 02:19 2015

how to get dts in LIVE555 Streaming Media

HI

I am using testRTSPClient to connect rtsp server,then get h264 video frame,in the "DummySink::afterGettingFrame()" function i already get h264 data and pts(presentationTime timestamp),however,i want to get dts(decoding time stamp) also,but where is the dts? thanks.

 

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
chung ikhwan | 26 Feb 02:23 2015
Picon

about remove proxyserver


Thanks for quick reply Ross,

I am sorry, Please remove prior mail. (subject is bad)

~ProxyServerMediaSession() {
..................
  // Then delete our state:
  Medium::close(fClientMediaSession);  //////////////////=> this instance is
removed before above code.

 MediaSession  *fClientMediaSession's element  fSubsessionHead pointer is
0x053da908  this content is destroyed..

 but

 in ~ProxyServerMediaSubsession()
  &fClientMediaSubsession is 0x053da908
 two pointer is same

if (fClientMediaSubsession.rtcpInstance() != NULL) { 
    fClientMediaSubsession.rtcpInstance()->setByeHandler(NULL,
NULL);////////////// Crash occured
  }

 and then this code referenced already destroyed pointer.

Thanks and Regards,
Ikhwan chung
chung ikhwan | 26 Feb 01:42 2015
Picon

Re: live-devel Digest, Vol 135, Issue 8


Thanks for quick reply Ross,

~ProxyServerMediaSession() {
..................
  // Then delete our state:
  Medium::close(fClientMediaSession);  //////////////////=> this instance is
removed before above code.

 MediaSession  *fClientMediaSession's element
 fSubsessionHead pointer is 0x053da908
 this content is destroyed..

 but

 in ~ProxyServerMediaSubsession()
  &fClientMediaSubsession is 0x053da908
 two pointer is same

if (fClientMediaSubsession.rtcpInstance() != NULL) { 
    fClientMediaSubsession.rtcpInstance()->setByeHandler(NULL,
NULL);////////////// Crash occured
  }

 and then this code referenced already destroyed pointer.

Thanks and Regards,
Ikhwan chung
chung ikhwan | 25 Feb 06:57 2015
Picon

about remove proxyserver

Hello,

 

I ran into a crash when removing the proxy server media session from our proxy server.

For removing my proxyserver, I use removeServerMediaSession(proxyServerStreamName) by triggerEvent.

 

ProxyServerMediaSubsession::~ProxyServerMediaSubsession() {
  if (verbosityLevel() > 0) {
    envir() << *this << "::~ProxyServerMediaSubsession()\n";
  }

  if (fClientMediaSubsession.rtcpInstance() != NULL) { 
    fClientMediaSubsession.rtcpInstance()->setByeHandler(NULL, NULL);////////////// Crash occured
  }
}

 

Maybe, I guess that is caused below code.

 

ProxyServerMediaSession::~ProxyServerMediaSession() {
  if (fVerbosityLevel > 0) {
    envir() << *this << "::~ProxyServerMediaSession()\n";
  }

  // Begin by sending a "TEARDOWN" command (without checking for a response):
  if (fProxyRTSPClient != NULL && fClientMediaSession != NULL) {
    fProxyRTSPClient->sendTeardownCommand(*fClientMediaSession, NULL, fProxyRTSPClient->auth());
  }

  // Then delete our state:
  Medium::close(fClientMediaSession);  //////////////////=> this instance is removed before above code.
  Medium::close(fProxyRTSPClient);
  delete fPresentationTimeSessionNormalizer;


Thanks and Regards,
Ikhwan chung

 

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Eric Pronovost | 24 Feb 16:05 2015
Picon

client port validation

An RTSP client application that connects to my RTSP server is launched in multi instances. However, it always start with client_port 9000. 

CSeq: 2
Transport: RTP/AVP;unicast;client_port=9000-9001
etc...

When the first instance is launched, it works with port 9000. The second instance is then launched and tries port 9000 again. It doesn't work, so a TEARDOWN is performed. The problem is that the teardown of the second instance is stopping the video of the first instance.

By debugging, I discovered that, inside StreamState::endPlaying(), the following call:
if (fRTPgs != NULL) fRTPgs->removeDestination(dests->addr, dests->rtpPort);
if (fRTCPgs != NULL) fRTCPgs->removeDestination(dests->addr, dests->rtcpPort);
will stop the video from the first instance, since the ports are the same.


I coded the following workaround:

In ::handleCmd_SETUP(), before the call to subsession->getStreamParameters(), I added a custom function that checks if the address/ports are already in use:

bool bAlreadyInUse = subsession->destinationsAlreadyInUse(ourClientConnection->fClientAddr.sin_addr.s_addr, clientRTPPort, clientRTCPPort, tcpSocketNum, rtpChannelId, rtcpChannelId, destinationAddress);
    if (bAlreadyInUse)
       break;


Here's the code to my custom function:

bool OnDemandServerMediaSubsession::destinationsAlreadyInUse(netAddressBits clientAddress, Port const& clientRTPPort,
   Port const& clientRTCPPort,
   int tcpSocketNum,
   unsigned char rtpChannelId,
   unsigned char rtcpChannelId,
   netAddressBits& destinationAddress)
{
   if (tcpSocketNum >= 0)  // TCP
      return false;

   if (destinationAddress == 0) destinationAddress = clientAddress;
   struct in_addr destinationAddr; destinationAddr.s_addr = destinationAddress;

   Destinations* destinations;
   if (tcpSocketNum < 0) { // UDP
      destinations = new Destinations(destinationAddr, clientRTPPort, clientRTCPPort);
   }
   else { // TCP
      destinations = new Destinations(tcpSocketNum, rtpChannelId, rtcpChannelId);
   }

   HashTable::Iterator* iter = HashTable::Iterator::create(*fDestinationsHashTable);
   Destinations* dests;
   char const* key; // dummy
   bool bAlreadyExist = false;
   while ((dests = (Destinations*)(iter->next(key))) != NULL)
   {
      if (dests->addr.S_un.S_addr == destinations->addr.S_un.S_addr)
      {
         if ((dests->rtcpPort.num() == destinations->rtcpPort.num()) || (dests->rtpPort.num() == destinations->rtpPort.num()))
            bAlreadyExist = true;
      }
   }
   delete iter;
   return bAlreadyExist;
}


With this workaround, the second instance won't stop the video of the first instance, and it will receive RTSP/1.0 454 Session Not Found.

I consider this as a patch, not sure what the best solution should be... any suggestions?
_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Gilles Chanteperdrix | 22 Feb 13:55 2015

pause issue

Hi Ross,

I think I got to the bottom of my issues using RTSP pause with a
server using live555 issue, and I believe there might be an issue
with live555.

The source of the problem is that when resuming from a pause, a few
packets are sent with a date in the past. If you take
MultiFramedRTPSink for instance, when restarting from a pause,
"continuePlaying" gets called, which ends up calling packFrame, and
packFrame will reuse the overflow data presentationTime when there
is some overflow data, and this presentationTime is before the time
of the pause. Even if MultiFramedRTPSink could be fixed to
avoid that (for instance by waiting to have sent all overflow data
before pausing), nothing prevents a framer or filter to do exactly
the same thing.

This has two consequences: 

- a frequent one, in MultiFramedRTPSink, fInitialPresentationTime
may be set to this date in the past. But this only has a consequence
when resuming from the next pause (so, you need to pause and resume
twice to observe the problem), that the computed start NPT is wrong.

- a less frequent one, this date in the past is used in
RTPSink::convertToRTPTimestamp to compute the new timestamp base
when resuming, and this value ends up being off as well.

The following patch avoid these issues:
diff --git a/liveMedia/MultiFramedRTPSink.cpp b/liveMedia/MultiFramedRTPSink.cpp
index c86ff03..4e36719 100644
--- a/liveMedia/MultiFramedRTPSink.cpp
+++ b/liveMedia/MultiFramedRTPSink.cpp
 <at>  <at>  -241,7 +241,7  <at>  <at>  void MultiFramedRTPSink

   fMostRecentPresentationTime = presentationTime;
   if (fInitialPresentationTime.tv_sec == 0 && fInitialPresentationTime.tv_usec 
== 0) {
-    fInitialPresentationTime = presentationTime;
+    gettimeofday(&fInitialPresentationTime, NULL);
   }    

   if (numTruncatedBytes > 0) {
diff --git a/liveMedia/RTPSink.cpp b/liveMedia/RTPSink.cpp
index 21e73e9..7ffa4ba 100644
--- a/liveMedia/RTPSink.cpp
+++ b/liveMedia/RTPSink.cpp
 <at>  <at>  -78,9 +78,16  <at>  <at>  u_int32_t RTPSink::convertToRTPTimestamp(struct timeval tv) {

   // Then add this to our 'timestamp base':
   if (fNextTimestampHasBeenPreset) {
+    u_int32_t baseIncrement;
+    struct timeval now;
+    gettimeofday(&now, NULL);
+
+    baseIncrement = (fTimestampFrequency*now.tv_sec);
+    baseIncrement += (u_int32_t)(fTimestampFrequency*(now.tv_usec/1000000.0) + 0.5); // note: rounding
+
     // Make the returned timestamp the same as the current "fTimestampBase",
     // so that timestamps begin with the value that was previously preset:
-    fTimestampBase -= timestampIncrement;
+    fTimestampBase -= baseIncrement;
     fNextTimestampHasBeenPreset = False;
   }

This may be thought as papering over the real bug, but it seems much
easier to me to accept these wrong timestamps and let the client cope
with them (the client will probably let a video with a wrong
timestamp reach the decoder and get rid of it before display, in
case this is a reference frame) than to try and avoid them.

Something I also discovered, is that MultiFramedRTPSink will start
sending packets as soon as StreamState::startPlaying is called, so
that some packets will be sent with the old timestamp base, before
presetNextTimestamp is called in
OnDemandServerMediaSession::startStream, but I have not found any
negative consequences of that (well, except that the client drops the
packets because they have wrong timestamps). I have tried calling
currentSeqNo and presetNextTimestamp before
StreamState::startPlaying, but ended up with de-synchronized audio
and video tracks.

Sorry for the long mail.
Regards.

--

-- 
					    Gilles.
Gilles Chanteperdrix | 22 Feb 00:09 2015

[PATCH] Fix NPT calculation for OnDemand server

---
 liveMedia/OnDemandServerMediaSubsession.cpp |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/liveMedia/OnDemandServerMediaSubsession.cpp b/liveMedia/OnDemandServerMediaSubsession.cpp
index 2f0a8d2..fd3f3fa 100644
--- a/liveMedia/OnDemandServerMediaSubsession.cpp
+++ b/liveMedia/OnDemandServerMediaSubsession.cpp
 <at>  <at>  -335,7 +335,7  <at>  <at>  float OnDemandServerMediaSubsession::getCurrentNPT(void* streamToken) {

     return streamState->startNPT()
       + (rtpSink->mostRecentPresentationTime().tv_sec - rtpSink->initialPresentationTime().tv_sec)
-      + (rtpSink->mostRecentPresentationTime().tv_sec - rtpSink->initialPresentationTime().tv_sec)/1000000.0f;
+      + (rtpSink->mostRecentPresentationTime().tv_usec - rtpSink->initialPresentationTime().tv_usec)/1000000.0f;
   } while (0);

   return 0.0;
--

-- 
1.7.10.4
Giovanni Iamonte | 21 Feb 19:33 2015
Picon

Re: RSTP Live streaming from USB camera (Ross Finlayson)

Hi Ross

 

We use ffmpeg and live555 to generate an H264 streaming in a Windows environment.

As I said in my previous mail, after your last suggestion the streaming works as we expect.

 

Nevertheless, when we play with the H264 parameters, to have better quality,

and the bitrate grows over 2 Mbps, we start to notice some artefacts in the player.

 

We went inside the problem and we realized that there were several lost packets.

Looking at the source code, in the "writeSocket" function inside

GroupsockHelper.cpp file we saw that there's no check for error for the "sendto" call.

 

We have tried and tested with success a way to solve the problem:

1) first of all, we modified the "writeSocket" function by adding an

error check when the "sendto" is called, in case of fail, it retries the call for a max of 3 time.

 

2) secondly, we programmatically increased the socket buffer by

adding the call to "setsockopt" in Live555ServerMediaSubsession :: createNewRTPSink

 

What do you think about? Is interesting for you to consider our code?

 

Bye

 

________________________________________________________________

Ing. Giovanni Iamonte

Area Tecnologie e sviluppi

Quintetto Srl – Pont Saint Martin (AO)

( mobile: +39 393 9196310

( tel: +39 0165 1845290

+ e-mail: iamonte <at> quintetto.it

[ web: www.quintetto.it

 

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Gilles Chanteperdrix | 16 Feb 10:56 2015

About pausing in live555.

Hi,

when resuming playing after a pause, the relation between RTP
timestamps and NPT changes, there is an additional gap corresponding
to the pause time, which may even cause the RTP timetamps to wrap.
Is this the expected behaviour? Or did I implemented pausing
incorrectly?

Thanks in advance.
Regards.

--

-- 
					    Gilles.

Gmane