srtp support for the live555 library

Hi ,


I’m considering using live555 for RTSP server support. However I require srtp support.  FAQ indicates that’s in the TODO list .  Do you have an Idea on timeline for  srtp support?



Thank you,


Unsubscribe from our commercial electronic messages.
Désabonner de nos messages électroniques commerciaux.
live-devel mailing list
live-devel <at> lists.live555.com
Punita Pandya | 20 May 16:03 2016

Replacement of DarwinInjector

Hello Sir,

We are using 2014 old Live555 MediaServer version.
And we are suing RTSPClient using DarwinInjector.

Now we need to upgrade Live555 library with latest version.

May I now which class is use for DarwinInjector class

eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are
intended solely for the use of the addressee and may contain legally privileged and confidential
information. If the reader of this message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, you are hereby notified that any
dissemination, distribution, copying, or other use of this message or its attachments is strictly
prohibited. If you have received this message in error, please notify the sender immediately by replying
to this message and please delete it from your c
 omputer. Any views expressed in this message are those of the individual sender unless otherwise stated.
Company has taken enough precautions to prevent the spread of viruses. However the c!
 ompany accepts no liability for any damage caused by any virus transmitted by this email. *************************************************************************************************************************************************************
Ross Finlayson | 18 May 13:57 2016

An update on the LIVE555 WebRTC proxying demo

For those of you who have been following our ongoing project for WebRTC integration - demonstrated at


In this demo, you can now enter a “rtsp://“ URL for your own (publicly-accessible) RTSP stream, and our
server will proxy this to WebRTC.  The resulting web page can be accessed by any WebRTC-compatible web
browser - Chrome, Firefox, Opera (except on iOS) - including those running behind a NAT.  (The RTSP stream,
however, must be accessible by our server, and therefore must be on the public Internet; *not* behind a NAT.)

The RTSP stream must contain a H.264, MPEG-4, or JPEG video track; these will be translated to VP8 for
WebRTC.  (Any audio track in the stream is ignored.)

Ross Finlayson
Live Networks, Inc.

live-devel mailing list
live-devel <at> lists.live555.com
Benfield, Marshall H | 17 May 14:54 2016

Updating a tsx with live data

Hello Everyone,

  I saw this thread from 2014 and was wondering if this functionality was ever implemented. We have a similar need:


>  As some people noted, it would be possible to implement the mechanism that Michael Chapman’s asking for (rewind/seek backwards) in the client - but it

>  shouldn’t be necessary, because the RTSP protocol already has a mechanism for this - and, as Michael noted, RTSP is already used for ‘off line’

>  playback, so it makes sense to try to use the same RTSP client for both mechanisms.



>  So yes, it should be possible for me to update the “MPEG2TransportStreamIndexer” application to continually extend the index file if the underlying

>  Transport Stream file keeps growing.  (This will also require a small change to the RTSP server’s Transport Stream 'trick play' code to allow for the

>  possibility of the index file growing after it was first read.)



>  I have only limited Internet access over the next few weeks, but I’ll see if I can make this change sometime before mid-December.  (If you are

>  interested in paying money to expedite this, let me know by separate email.)

>  Ross Finlayson

>  Live Networks, Inc.


Unfortunately, I looked through the release notes and didn’t see an entry that looked similar to this.


If it is not possible to update the tsx file as the stream is being recorded, are there strategies you have found that allow you do it?


One thing that comes to mind is to have one process save the original stream to a .ts file. Also have another process save off 1 minute chunks of the stream into smaller .ts files. Then index the 1 minute .ts files (creating small .tsx files) and append the small .tsx files into one master .tsx file.

I don’t know if the format of the final .tsx file would be valid or not and I don’t know if the Live555 Media Server would pick up the updated .tsx data as it streams the video.


Any help would be appreciated.



Marshall Benfield


live-devel mailing list
live-devel <at> lists.live555.com
Gilles Chanteperdrix | 15 May 22:35 2016

Invalid packets with Vorbis RTP Sink


Some time ago (actually, in 2013):

I reported an issue with Vorbis RTP Sink: valgrind would whine that
the sendto syscall was accessing some uninitialized data, and the
RTSP clients (vlc, using live555 for RTP depacketization, and
ffplay, using ffmpeg) would complain about invalid vorbis data when
decoding the frames received via RTP.
The file allowing to reproduce this issue being:

Disabling the packing of multiple vorbis frames in one packet
avoided the issue, so I did it in my local copy of live555, but this
caused issues with files containing very small frames.

So, I finally had a look at the issue, I made a test program
combining live555 media server and testRTSPClient, the server would
serve the problematic file on the address, the RTSP client
would connect to the server and also demux the file, and compare the
frames received via RTP with the data extracted directly from the
file. I can post this test program somewhere if anyone is interested.

When the problem happens, the data extracted from the RTP packet
are (much) larger than the data extracted from the file, and the
"good data" is preceded by two bytes.

It seems the problem happens in MultiFramedRTPSink, when a frame
would overflow the packet size, and is put aside as overflow data.
When the overflow data are reused, and setFrameSpecificHeaderBytes()
is called by the vorbis doSpecialFrameHandling() method the offset
used to store the frame specific header is an offset that was valid
when the frame was at the end of the previous packet. This causes
the frame size to be larger than it should.

Recomputing the frame specific header offset as in the following
patch before reusing the overflow data seems to avoid the issue:

diff -Naurdp live/liveMedia/MultiFramedRTPSink.cpp live.fixed/liveMedia/MultiFramedRTPSink.cpp
--- live/liveMedia/MultiFramedRTPSink.cpp	2016-04-21 20:56:32.000000000 +0200
+++ live.fixed/liveMedia/MultiFramedRTPSink.cpp	2016-05-15 21:57:44.423448155 +0200
 <at>  <at>  -201,6 +201,10  <at>  <at>  void MultiFramedRTPSink::buildAndSendPac
 void MultiFramedRTPSink::packFrame() {
   // Get the next frame.

+  fCurFrameSpecificHeaderPosition = fOutBuf->curPacketSize();
+  fCurFrameSpecificHeaderSize = frameSpecificHeaderSize();
+  fOutBuf->skipBytes(fCurFrameSpecificHeaderSize);
   // First, see if we have an overflow frame that was too big for the last pkt
   if (fOutBuf->haveOverflowData()) {
     // Use this frame before reading a new one from the source
 <at>  <at>  -214,9 +218,6  <at>  <at>  void MultiFramedRTPSink::packFrame() {
     // Normal case: we need to read a new frame from the source
     if (fSource == NULL) return;

-    fCurFrameSpecificHeaderPosition = fOutBuf->curPacketSize();
-    fCurFrameSpecificHeaderSize = frameSpecificHeaderSize();
-    fOutBuf->skipBytes(fCurFrameSpecificHeaderSize);
     fTotalFrameSpecificHeaderSizes += fCurFrameSpecificHeaderSize;

     fSource->getNextFrame(fOutBuf->curPtr(), fOutBuf->totalBytesAvailable(),



Ross Finlayson | 9 May 04:57 2016

Online forums (or mailing lists) used by developers of network cameras?

Can anyone recommend any online forums (or mailing lists) that are commonly used by companies that make
network video cameras?  (Not companies that *use* network video cameras; companies that *make* network
video cameras.)

Ross Finlayson
Live Networks, Inc.
Deanna Earley | 26 Apr 10:34 2016

liveMedia repositories

Good morning all (or whatever time of day it is for you)

Firstly, I'm aware of the policy not to maintain any official source repositories or archived versions.

Unfortunately, many of us have much larger projects, and in many cases pull in external libraries.
At least in my case, I've found this easier when I can just "hg pull -U" with incremental updates whenever I
need to do a code update.
This also helps when upgrading old code as you can upgrade in steps, testing as you go.

As such, I have each released archive pulled into repository, and pushed to GitHub and Bitbucket (for git
and mercurial respectively).

They include all the releases I could find back to 2004 (most of them from 2011 onwards), and are the full,
unmodified contents of the archives, less any temporary/debug files.

To be absolutely clear, these are unofficial mirrors and provided on a best effort basis.

Kind regards


Deanna Earley | Lead developer | icatchercctv

w: www.icode.co.uk/icatcher | t: 01329 835335 | f: 01329 835338
Registered Office : 71 The Hundred, Romsey, SO51 8BZ. Company Number : 03428325
Eric_Hsieh | 26 Apr 09:00 2016

How to update SDPLines info?

Hi Ross,

Run rtsp server based on OnDemandServerMediaSubsession class.
We found the server will always return the same SDP into back to the rtsp client, even we update the NEW SDP
info when call createNewRTPSink. So, my question is, how to control live555 library update SDP info?
Thanks a lot.
This electronic mail transmission is intended only for the named recipient. It contains information
which may be privileged,confidential and exempt from disclosure under applicable law. Dissemination,
distribution, or copying of this communication by anyone other than the recipient or the recipient's
agent is strictly prohibited. If this electronic mail transmission is received in error, Please notify
us immediately and delete the message and all attachments of it from your computer system. Thank you for
your cooperation.
Ayuso, Fermin | 21 Apr 15:22 2016

Smaller MTU

Hi all,


I need some help.


I have a RTSP Server implementation working ok, based on testOnDemandRTSPServer.

Now, I want to apply this implementation in a network that has an smaller MTU than the standard one(MTU:1300).

Live555 is very smart, so the packets throw through this network are splitted in two parts, that’s perfect, but the second packet is small and causes that network has to deal with more packets.

In order to reduce the number of packets which my server sends through the net, I want to tell Live555 to reduce the size of the packets to fit into the smaller MTU.


I read that I can change it in MultiFramedRTPSink, but I don’t use this class in my code, so changing setPacketSizes doesn’t seem to change anything.


How can I do that?


Thanks for all.

Notice to recipient: This email is meant for only the intended recipient of the transmission, and may be a communication privileged by law, subject to export control restrictions or that otherwise contains proprietary information. If you receive this email by mistake, please notify us immediately by replying to this message and then destroy it and do not review, disclose, copy or distribute it. Thank you in advance for your cooperation.
live-devel mailing list
live-devel <at> lists.live555.com
Ben Rush | 19 Apr 22:32 2016

strange behavior with Android 5.0 lollipop media player

We've been using Live555 very successfully now for a while but have encountered a quirk that is likely due to a bug or oddity in the media player on Android 5.0 Lollipop. The problem is that it's becoming a bit of a showstopper for us (a major client is using this particular version of Android), and I'm wondering if there is possibly a way to work around the player's quirk. I know this is likely not considered a bug in Live555, but perhaps there's a quick setting in the server that can save us for the time being. 

It's easy to duplicate (at least on these phones). If you spin up Live555 and connect the phone's native MediaPlayer, everything works fine. However, if any client is already connected to the server, then the phones NEVER work. The stream never shows up. 

Investigating with Wireshark shows that the RTSP and RTCP handshakes are identical in both situations with one exception: the initial RTCP Sender Report sent by the server to the phone when the phone is connecting the first time has a Sender's Packet count of 0, but when a client has already been streaming on the server, the packet count is >0. In looking at the specification it's unclear as to whether this should be zero for a new client, or whether client connecting to an already running stream should expect this to be >0, but since this is the ONLY difference, I have to imagine this is the "problem". But I'm going to assume it's a bug in the CLIENT since this is the first time we've EVER seen this issue. 

One more reason I think this is the issue: if I turn off reuseFirstSource when creating the session, the phones connect just fine regardless of their order. But, again, having this option set to TRUE seems to be good for performance reasons. 

I guess what I'm looking for is confirmation that the Sender's packet count SHOULD be >0 for a client connecting to an already running stream, and as to whether anybody has any experience in dealing with this situation or ideas on how to get around it. 

Thanks in advance. 

FYI - I can provide Wireshark files if you need. 
live-devel mailing list
live-devel <at> lists.live555.com
Saskia van Emst | 19 Apr 13:18 2016

ProxyServer switching backend source

Hi all,

First of all thanks a lot for the software ☺ 

For an IP camera, connected to wireless networks, I’m using the proxy so that the stream can be viewed
multiple times without increasing the bandwidth over the wireless link.

Now I am wondering if it is possible to let the proxy switch the backend stream to a different rtsp url. When a
certain event is triggered (e.g. the connection switches from Wi-Fi to 4G) I would like the proxy to serve a
different back-end stream on the same front-end url.

For example:

1. rtsp://proxyserver/video-stream <- rtsp://ip-cam/highquality
2. Connection switches, some trigger is sent to the proxy server
3. rtsp://proxyserver/video-stream <- rtsp://ip-cam/lowquality

With the REGISTER command using the included test program I can include a new stream, but when I specify an
existing [proxy-URL-suffix] I get '451 Invalid parameter'.
I guess this means this scenario is simply not supported, and only new back-end streams can be added?

Would it be possible to do something like this, and if so would it be very hard to implement or could there be a
quick fix?

If I change the image parameters in the camera then the stream keeps working so I guess it is possible to
change quality/resolution of a stream while it is being viewed.

Thanks for any input / ideas.

Best regards,

Saskia van Emst

live-devel mailing list
live-devel <at> lists.live555.com