Home > Software engineering >  Video player multithreaded processing several problems caused by the death cycle
Video player multithreaded processing several problems caused by the death cycle

Time:09-22

Made a video player, QT in own decoding library and rendering library, the basic idea is to open a child thread used for decoding, the main thread, I again in the two threads in the infinite loop, decoding, rendering, found that the CPU utilization rate is very high, trying to decode the child thread Sleep, the results could have normal play video edge of slow play, I was using a critical section mutually exclusive way to coordinate the two threads of the job, as the child thread code
 EnterCriticalSection (& amp; GcsAcessOneFrm); 
Sleep (10);
NRSize=pMainWnd - & gt; M_Framebuf. PutFrame (DECT. M_hDec, DECT. M_pInData, DECT m_rfp);
LeaveCriticalSection (& amp; GcsAcessOneFrm);

Use EVENT (EVENT), then remove the Sleep, reduce some of the CPU utilization, don't know whether occupancy rate reduced because events (EVENT), blocked threads, and before Sleep () with the method of thread hanging, although CPU usage decreased a lot, but this leads to a decoding speed slow, slow play?
If there is a suitable method to control the two thread synchronization?
In addition on the main thread, in the main thread when rendering play interface controls can still control, whether the main thread shouldn't apply colours to a drawing with the cycle of death waiting time to render the next frame?

CodePudding user response:

I think some of the qt if there is a similar message mapping mechanism of MFC, under the present a frame of time to render the child thread sends a message to the main thread rendering images, but such a writing problems: 1. The child thread will be blocked during the timing on that, can't continue to decode, 2. The child thread sends the message delay time is the main thread to perform rendering will be longer and unstable effects broadcast frame rate,

CodePudding user response:

no one answer it for me

CodePudding user response:

For the occupancy rate is another parameter is idle rate; Whether you have any things, the CPU has been run, frequency did not reduce, if you have a heavy task, the CPU is not so carefree, natural share will increase; Your task is very heavy, you still let it Sleep, no wonder cause caton,

CodePudding user response:

"Windows core programming"
  • Related