Lost some last frames while streaming video to RTMP using FFmpeg

[winwindg]

!!! Before submitting a new bug report, please ensure you have searched for any existing bugs. Duplicate issues or
questions that are overly simple or already addressed in the documentation will be removed without any
response.

Describe the bug
Lost some last frames while pushing video to RTMP using FFmpeg. Only when the next video streaming begins will the last few frames of the previous video be streaming out.

Attempts to resolve the issue by disabling GOP cache, using -fflags nobuffer, -flags low_delay, and -flvflags no_duration_filesize parameters proved ineffective.

Version
5.x, 6.x, v5.0.60.

To Reproduce
Steps to reproduce the behavior:

1. ffmpeg -re -i 1.mp4 -c copy -f flv rtmp://127.0.0.1/live/123456, will lost some last frames of 1.mp4
2. ffmpeg -re -i 2.mp4 -c copy -f flv rtmp://127.0.0.1/live/123456, will lost some last frames of 2.mp4
3. When playing rtmp://127.0.0.1/live/123456 with VLC, you will notice that the last few frames of each video are missing.

Expected behavior
Push the entire video stream, ensuring all frames are transmitted completely.

Screenshots
None

Additional context
None

[suzp1984]

SRS will send RTMP packet in bundle.

srs/trunk/src/app/srs_app_rtmp_conn.cpp

Lines 845 to 849 in 7951bf3

	#ifdef SRS_PERF_QUEUE_COND_WAIT
	// wait for message to incoming.
	// @see https://github.com/ossrs/srs/issues/257
	consumer->wait(mw_msgs, mw_sleep);
	#endif

The srs collect mw_msgs packets then send them together.
So, when the publish stream stopped, there are maybe still some packet cached there. So I call consumer->wakeup() when stream publish stopped, to make sure all packet send to player. But the player, ffplay, still seems missed a few frame. After I force closed the srs by ctrl-c. The last frames will play.

It seems the TCP socket cached the last few frame without send them. So I added the log to ffmpeg.
https://github.com/FFmpeg/FFmpeg/blob/4fc43e45f9e7ee50d8d244bcdea15b37b5614b9b/libavformat/tcp.c#L286-L300

The conclusion is that the packet all sent to ffplay. The ffplay always cache the last few frames until TCP socket closed by SRS. This is what I found, although it will not resolve this issue.