Chang, Dashan | 27 Feb 16:16 2015

Bug report of Live555ProxyServer



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!



Attachment (Live555ProxyServer.log): application/octet-stream, 157 KiB
live-devel mailing list
live-devel <at>
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>
夏江龙 | 26 Feb 02:19 2015

how to get dts in LIVE555 Streaming Media


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>
chung ikhwan | 26 Feb 02:23 2015

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..


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

if (fClientMediaSubsession.rtcpInstance() != NULL) { 
NULL);////////////// Crash occured

 and then this code referenced already destroyed pointer.

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

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..


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

if (fClientMediaSubsession.rtcpInstance() != NULL) { 
NULL);////////////// Crash occured

 and then this code referenced already destroyed pointer.

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

about remove proxyserver



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.
  delete fPresentationTimeSessionNormalizer;

Thanks and Regards,
Ikhwan chung


live-devel mailing list
live-devel <at>
Eric Pronovost | 24 Feb 16:05 2015

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

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)

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>
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.


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;

Giovanni Iamonte | 21 Feb 19:33 2015

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?





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>

[ web:


live-devel mailing list
live-devel <at>
Gilles Chanteperdrix | 16 Feb 10:56 2015

About pausing in live555.


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

Thanks in advance.