Multimedia development of the---live555 multithreading support, originally only single-threaded, single-channel

1) I Live555 a package, but the Live555 is single-threaded, there are too many global variables defined inside, I encapsulated the DLL library, in the client call, because more than one dialog box to use the code flow, I define multiple objects from the device side to receive the stream, to establish multiple connections, But when the code stream exits, and then exits the other one-way stream, there is a problem in the library because the global variables inside the Live555 are destroyed!

For the above question: my current solution is to isolate the global information:

Define a structure:

#define CLIENT_STREAM_NUM 4

Class Ourrtspclient;

typedef struct _RTSPGLOBAL
{
Ourrtspclient *prtspclient;
NetSDK *PNETSDK;
}rtspglobal;

//
Rtspglobal Strurtspglobal[client_stream_num];

So each stream corresponds to one of the array, it is made multithreaded, in the global callback function, according to the rtspclient*rtspclient pointer and the Strurtspgloball array of pointers in comparison, if the same, we know which stream corresponding to the connection, For example, when establishing sink in the Continueaftersetup function, we can judge as follows:

for (int i=0;i<client_stream_num;i++)
{
if (strurtspglobal[i].pnetsdk!=null)
{
if (strurtspglobal[i].prtspclient==rtspclient)
{
Scs.subsession->sink = Crtpmediasink::createnew (env, *scs.subsession,
(Rtpmediasinkcallback) Strurtspglobal[i].pnetsdk->rtspdatacallback,
(void *) &strurtspglobal[i],rtpmedaa_sink_receive_buffer_size, Rtspclient->url ());

Break
}
}

}

This allows the testrtspclient example to support multithreading.

2) The problem of Live555 of broken network

1) Re-connect the deadlock

1.1) If the decoding callback thread is placed in the NETSDK, using two event, when the Accept thread ends, send a signal that accepts the thread end, then in the decoding thread to determine the receiving thread signal, if there is a signal, send an exit decoding thread, send a decoding end of the signal;

1.2) When the time-out is re-connected, the first stop stream, and then restart Stream, stop the code stream, the data receiving thread will be eventloopwatchvariable=1, and wait for the decoding thread to end in the Stop function.

Waitforthreadexit (m_decodeexitevent);

This will cause a deadlock, because the Live555 is single-threaded, in the timeout function need to wait for the end of this thread, causing deadlock;

Workaround:

1) Use a separate heart jumper to achieve the re-connect function or the callback data to the client's decoding thread to achieve the re-connect function;

2) The Network Disconnect judgment method uses the delay queue to judge, the initialization time calls Noteliveness, and then each time receives the sink frame data, calls the noteliveness again, so if the network disconnects, after the timeout, can judge out After the doeventloop of the data receive thread, place the re-attached tag:

M_breconnect=true;

3) The work of the disconnection network cannot be placed in the function of livenesstimeouttask, otherwise it will cause a heavy connection deadlock, because live555 is single-threaded, and can only be re-connected in other threads; I put the callback to the client's decoding thread to implement the re-connection;

void Netsdk::noteliveness (void* clientdata,usageenvironment& env)
{

if (m_reconnecttime> 0)
{
Env.taskscheduler (). Rescheduledelayedtask (flivenesschecktask,m_reconnecttime*1000000, (TaskFunc*) Livenesstimeouttask, Clientdata);
}

}

void Netsdk::livenesstimeouttask (void* clientdata) {

TRACE ("Livenesstimeouttask run\n");
Rtspglobal *prtspglobal= (Rtspglobal *) clientdata;
Prtspglobal->pnetsdk->flivenesschecktask= NULL;
usageenvironment& env = Prtspglobal->prtspclient->envir (); Alias

Prtspglobal->pnetsdk->restopvideo ();

}

The reconnect process is as follows:

void NetSDK::D ecodethread (void *arg)
{
NetSDK *pthis= (netsdk*) arg;

while (!pthis->m_bquit)
{

if (Pthis->m_breconnect)
{
//
Pthis->restartvideo ();
pthis->m_breconnect=false;

}else
{
Pthis->imagedecodeandshow ();
}

}

SetEvent (pthis->m_decodeexitevent);

}

Which one has the better way, may as well tell me!

http://blog.csdn.net/smilestone_322/article/details/18319867

Multimedia development of the---live555 multithreading support, originally only single-threaded, single-channel