Sharmistha Chatterjee | 18 Dec 16:14 2014

SingleStep(): select() fails: Bad file descriptor

Hi All,

I am using live555ProxyServer in my multi-threaded application..The application will only use a single instance of proxyServer from only one of its thread. (no multi-thread handling of live555)

I ran the proxyServer provided in the example, and was able to stream successfully from a VLC client. Then I changed the live555ProxyServer.cpp to start the event-loop from a pthread.

The arvg argument of main was passed to the thread as void * and casted back inside the threadFunc.  argv variables are coming correctly inside threadfunc . 

Also the TaskScheduler and BasicUsage environment variable was created inside the pthread. In other words, all the code from main function has been moved to a pthread.

The event loop crashes inside BasicTaskScheduler:SingleStep. 

Can anyone please help with this problem, why it happens when I call eventloop from pthread func

int main(int argc, char** argv) {

   pthread_t tid;
   void *status;
   pthread_create(&tid, NULL, threadfun,  (void *)argv);
   printf("Created Pthread %d\n",*(int*)status);            


live-devel mailing list
live-devel <at>
정명수 | 18 Dec 09:10 2014

Could you give me guide how to stream RTP live source to RTSP server?

 Hi. live555 list members.
I'm using your live555 libraries for my application.
I wanna set RTSP relay server with RTP source stream which contain H.264.
I did some of step on testOnDemandRTSPServer.
Firstly, I added codes for reading RTP under sample code to add server media subsession for MPEG-2 TS.
The added codes indicate that create new server media subsession with my class(H264VideoRelayMediaSubsession) that is inherited OnDemandServerMediaSubsession class.
like this,
OutPacketBuffer::maxSize = 1000000;
ServerMediaSession* sms
    = ServerMediaSession::createNew(*env, streamName, streamName,
// parameters for createNew are not important. don't mind.
sms->addSubsession(H264VideoRelayMediaSubsession::createNew(*env, NULL, 90000));

Secondly, I had copied H264VideoFileServerMediaSubsession class and renamed it to "H264VideoRelayMediaSubsession"
And then, I had modified codes in 2 methods. (createNewStreamSource, createNewRTPSink)
See the codes below
FramedSource* H264VideoRelayMediaSubsession
 ::createNewStreamSource(unsigned /*clientSessionId*/, unsigned& estBitrate)
 estBitrate = 500; // kbps, estimate

  // Create a 'groupsock' object for receiving the input stream:
 char* inputAddressStr = "";
 struct in_addr inputAddress;
 inputAddress.s_addr = our_inet_addr(inputAddressStr);
 Port const inputPort(34000);
 unsigned char const inputTTL = 255; // we're only reading from this mcast group
 Groupsock *fInputGroupsock = new Groupsock(envir(), inputAddress, inputPort, inputTTL);
 // Create the video source:
  FramedSource* transportStreamSource;
 transportStreamSource = SimpleRTPSource::createNew(envir(), fInputGroupsock, 96, 90000, "video/H264", 0, False /*no 'M' bit*/);
  //transportStreamSource = H264VideoRTPSource::createNew(envir(), fInputGroupsock, 96, 90000);
 //return transportStreamSource;

 // Create a framer for the Video Elementary Stream:
  return H264VideoStreamDiscreteFramer::createNew(envir(), transportStreamSource);
 //return H264VideoStreamFramer::createNew(envir(), transportStreamSource);

RTPSink* H264VideoRelayMediaSubsession
 ::createNewRTPSink(Groupsock* rtpGroupsock,
 unsigned char rtpPayloadTypeIfDynamic,
 FramedSource* /*inputSource*/) {
 return H264VideoRTPSink::createNew(envir(), rtpGroupsock, rtpPayloadTypeIfDynamic);
 //return SimpleRTPSink::createNew(envir(), rtpGroupsock, 96, 90000, "video", "H264", 1, True, False /*no 'M' bit*/);

There are Some of comments for almost case that I had tried.
It was compiled and run well.
But It does not work or send any RTP to client(VLC player) in any case when I tried to connect.
I saw RTSP negotiations until PLAY on the captured packet.
Of course, RTP live source are streaming to my local on another desktop.
I will wait for your reply.
live-devel mailing list
live-devel <at>
Barbara Pacella | 17 Dec 18:19 2014

Discontinuous rtp stream using testOnDemandRtspServer with h264 mkv input files

Hi live555 staff.

I'm trying to stream some .mkv files using testOnDemandRtspServer. Files are captured from an Axis IP Camera, transcoded using x264 and libavcodec API and muxed in mkv format using libavformat API, and contain a single video track. When i play the files locally using vlc or ffplay the files play well, but if I try to stream them using testonDemandRtspServer, the rtp stream is often discontinuous and both ffplay and vlc disconnect. I'm using the 20-11-2014 live555 tarball, built and run on Linux CentOS 5 32bit.
I tried to stream the same files using the rtsp server provided by ffserver tool, and the output stream play well. You can download a sample .mkv file on (is it ok to use links on this mailing list? I checked the FAQ and didn't find anything, I'm sorry if it isn't ok )
Please let me know if there is any incompatibility between the live555 server and the way the file is encoded/muxed (I could change x264 encoding parameters) or if this is a bug in the live555 lib.

Kind Regards,
live-devel mailing list
live-devel <at>
u8818test | 17 Dec 09:46 2014

there is a bug when play HLS stream

When I use safari connect to live555 and request treansport stream, at each time of "getStreamParameters", like the following:
   Port clientRTPPort(0), clientRTCPPort(0), serverRTPPort(0), serverRTCPPort(0);
   netAddressBits destinationAddress = 0;
   u_int8_t destinationTTL = 0;
   Boolean isMulticast = False;
   void* streamToken;
   subsession->getStreamParameters(fClientSessionId, 0, clientRTPPort,clientRTCPPort, -1,0,0, \
    destinationAddress,destinationTTL, isMulticast, serverRTPPort,serverRTCPPort, streamToken);
it will do the proces:
FramedSource* MPEG2TransportFileServerMediaSubsession
    ::createNewStreamSource(unsigned clientSessionId, unsigned& estBitrate)
but the privious FramedSource create by createNewStreamSource have not been destroyed, and I have played the opened file point:

ByteStreamFileSource *ByteStreamFileSource::createNew(UsageEnvironment& env, char const* fileName,
    unsigned preferredFrameSize,
    unsigned playTimePerFrame) {
  FILE* fid = OpenInputFile(env, fileName);
  if (fid == NULL) return NULL;
 printf("==========================fid is %p\n", fid);
  ByteStreamFileSource* newSource
    = new ByteStreamFileSource(env, fid, preferredFrameSize, playTimePerFrame);
  newSource->fFileSize = GetFileSize(fileName, fid);
  return newSource;
the output result is different with each other, I think this is a bug, as time go long, it will occupy all the fd, isn't it?
live-devel mailing list
live-devel <at>
Jian Zhang | 17 Dec 04:15 2014

How to import live555 source code into eclipse project?

Hi developers, I don't know how to import the source code into an eclipse project, give me some advises please.
live-devel mailing list
live-devel <at>
u8818test | 16 Dec 07:51 2014

About live555 support real time HLS

Hello, dear friend:
I want to implement real time HLS by using live555, and I want to known that:
1.How does the index file(.m3u8 file) shoud be?
2.How to get source stream, the original stream source is H264 from camera or IPC, can I use the original stream source as the MPEG2 ts stream?
3.As the testH264VideoToTransportStream tool has something wrong with change H264 stream to ts stream when use the safari browser as the client, can you help me solve the problem?
Really need your help, wait for your response, thans very much!
live-devel mailing list
live-devel <at>
Deepak Agasibagil | 16 Dec 14:00 2014

openRTSP frame loss


I am using 'ip-camera' to stream the video(output of ip-camera is in H.264 format)
and i am using the openRTSP client capture the stream to a file in mp4 format.

However, when i play the captured video i notice that first few seconds(1-2 sec) of
video is not clear and while playing video it seems to be stopped and played again
for evary 4-5 seconds gap.

The command used to capture the video stream:

openRTSP -d 20 -4 -b 5120000 -B 5120000 -f 15 -w 704 -h 576 \
"rtsp://admin:admin <at>" > open-rtsp-video.mp4

what is the correct way to capture the stream without loosing any frames.
i had also altered the buffer size, but the problem is still present.

live-devel mailing list
live-devel <at>
Deanna Earley | 16 Dec 16:29 2014

liveMedia not sending any data on Windows with liveMedia 2014.12.13

Hi Ross.

I've just updating our app to use liveMedia 2014.12.13 and have come across a problem with the recent
changes for FD_SET in 2014.12.11.

createSocket()/socket() on Windows are returning socket descriptors with values up on the high hundreds
(880, 892, etc).
This value gets passed to connect() which currently returns EWOULDBLOCK, and so is passed to setBackgroundHandling().
At this point, it hits the new FD_SETSIZE check:

if (socketNum >= (int)(FD_SETSIZE)) return;
(FD_SETSIZE is 64)

This results in the background handling not being added and the connection not progressing any further.
If I comment out that check then it connects as expected.

I'm not sure on the BSD implementation, but isn't the actual limit (specified with FD_SETSIZE) a number of
descriptors, not their absolute values?
Also, on Windows, this limit can be redefined and increased so is not a hard limit in the API.

What are your thoughts on this?



Deanna Earley | Lead developer | icatchercctv

w: | t: 01329 835335 | f: 01329 835338
Registered Office : 71 The Hundred, Romsey, SO51 8BZ. Company Number : 03428325
Ogden, Nick | 16 Dec 15:13 2014

RTCP APP packet handling

Hi Ross.


We have a need to handle RTCP APP packets in our application. I notice from the Live555 RTCPInstance code that they are currently ignored.


If we were to implement a way for a subclass of OnDemandMediaSubsession to provide a custom handler for APP packets, in a similar way that handlers are provided for the SR and RR packets, would you be likely to accept this as a patch?


Kind Regards


Nick Ogden


G4S Technology

Tel:    +44 (0) 1684 857299          
nick.ogden <at>

Challenge House, International Drive, Tewkesbury, Gloucestershire, GL20 8UQ, UK

P Please consider the environment before printing this email


The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.
live-devel mailing list
live-devel <at>
Ralf Globisch | 15 Dec 19:40 2014

ServerMediaSubsession::getStreamParameters parameter change request

Hi Ross,

Would you be willing to add the "fullRequestStr" parameter of
RTSPServer::RTSPClientSession::handleCmd_SETUP as an additional parameter to the
ServerMediaSubsession::getStreamParameters method?

We had previously overridden ServerMediaSubsession::getStreamParameters in one of our subclasses for
the purpose of client connection management
and now to add DRM-related functionality we also need to associate "fOurSessionId" with the user name
which can be parsed out of the Authorization 
header in "fullRequestStr".

If you agree to add the parameter we would of course supply a patch. Otherwise, we would be grateful if you
have an alternative suggestion to 
associate the live555 session id with the user name from the context of a ServerMediaSubsession subclass.

We have thought of duplicating and adapting the code of
RTSPServer::RTSPClientSession::handleCmd_SETUP in our subclass of 
RTSPServer::RTSPClientSession but that does not seem like a good solution to me.

Thanks for your time,


This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and
implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.

Please consider the environment before printing this email. | 12 Dec 17:17 2014

Struggling with a stange behavior

 Dear Ross, I solved the problem.

The behaviour happened when I set the tunneling over TCP.
When an IP camera went down, closing the streaming, I invoked the shutdown function (as the testRTSPClient) on the  delayed event. When the camera turned on and  my sw started a new RTSP connection (client) at the end of the program Valgrind said me that I lost 60 byte in a past H264BufferdPackedFactory::createNewPacket.

Changing #define REQUEST_STREAMING_OVER_TCP false I found out the this problem is solved.
Unfortunately I don't have a technical answer to this behaviour, but I ran so many time Valgrind using this configuration and the answer is always the same: 0 byte lost, no leaks.


live-devel mailing list
live-devel <at>