Live555 push RTSP audio and video stream summary (III) flower screen problem caused by pushing H264 real-time stream

live555 do RTSP Server When pushing real-time streams , The solution to the flower screen problem
There should be many places that can be optimized , At present, only 3 Strategy solutions ：

Due to live555 The complex classes in the error are very unfamiliar , These are the conclusions after simple debugging ：

1.StreamParser.cpp

As I understand it , This parameter represents a frame H264 The size of the data , Default 150K, If the resolution is large , It is likely to exceed the size , Maybe every frame will lose data and splash the screen ---------> But I just changed ; There is no actual change to large resolution verification

#define BANK_SIZE 800000 //300 -> 800

2. modify maxSize size

OutPacketBuffer::maxSize = 1000000; // 

stay H264FramedLiveSource::doGetNextFrame() in , It's usually right H264 Do the operation of memory copy ：

memcpy(fTo ,video_buf,fMaxSize);

fTo yes live555 Released pointer , The maximum memory it points to is maxSize , With every turn fTo Copy the data ,fMaxSize From maxSize Slowly decrease , until 0, Then point to another maxSize Size of memory

therefore What I see is ： take maxSize The size is from 200k increase , You will find that the problem of flower screen has been improved , however , It will still spend dozens of seconds

3. utilize FrameSource Medium fNumTruncatedBytescans

And then the last one ：, With every turn fTo Copy the data ,fMaxSize From maxSize Slowly decrease , until 0, Then point to another maxSize Size of memory , So in fTo Of buf When it is about to run out , The last frame H264 The data can't be put , Will put the data that can't be put , I threw it away manually , Then it's time to spend the screen ！ Meow

that fNumTruncatedBytescans yes FrameSource One of the parameters in , It means the number of discarded bags , But in fact, direct operation of it has no effect . Only one number can be customized to implement my idea ：
every time fTo When exhausted , Save the lost data locally , Next callback doGetNextFrame() when , First write in the lost data , Then write this time 264 Put the bag in the back .
because H264 Yes, there is NALU Of , There are strict head and tail marks ; So it seems OK Of
then ,live555 Of buf Not directly fTo the buf, Not this buf Only one frame of data can be saved , This is also the wrong idea before

Upper pseudo code ：

void H264FramedLiveSource::doGetNextFrame()
{
    

      	int ret = 0;
		int h264_total_size = 0;
		int64_t timeStamp;
		unsigned char video_buf[MAX_VDATA_SIZE];
		memset(video_buf,0,sizeof(video_buf));
		
		getH264Data(&h264_total_size,&timeStamp ,video_buf);

		if(h264_total_size > fMaxSize) {
     // buff Exhausted frames 
			memcpy(fTo ,video_buf,fMaxSize);
			memcpy(truncatedBytes, video_buf+fMaxSize,h264_total_size-fMaxSize);
			fNumTruncatedBytes = h264_total_size - fMaxSize;
			NumTruncatedBytes = h264_total_size - fMaxSize;
			fFrameSize = fMaxSize;
		} 
		else 
		{
    
			if(NumTruncatedBytes != 0)
			{
    
				memcpy(fTo ,truncatedBytes,NumTruncatedBytes);
				memcpy(fTo+NumTruncatedBytes ,video_buf,h264_total_size);
				fFrameSize = h264_total_size+NumTruncatedBytes;
				fNumTruncatedBytes = 0;
				NumTruncatedBytes = 0;
				memset(truncatedBytes,0,sizeof(truncatedBytes));
			}
			else
			{
    
				memset(truncatedBytes,0,sizeof(truncatedBytes));	
				memcpy(fTo ,video_buf,h264_total_size);
				fFrameSize = h264_total_size;
				fNumTruncatedBytes = 0;
				NumTruncatedBytes = 0;
			}
		}

    FramedSource::afterGetting(this);

    return;
}