Av_interleaved_write_frame Exit slower

Use LIBVLC to do the live push-flow engine
In the case of poor networks, it is necessary to turn off the live broadcast and re-launch it.
In this process, the push-stream engine restarts, requiring a quick response.
In fact, the test results found that the engine shut-down interface often happens to get stuck.
Later the tracking code, located in the S_rtmp_send_thread ()
One sentence:
ret = Av_interleaved_write_frame (Formatcontext, PKT);
This method in the case of a better network, usually a few milliseconds to return the success of the send.
Then in the case of poor network, will remain stuck here, no return ...

Tracking FFmpeg code, the implementation of this method in MUX.C
Libavformat/mux.c
Av_interleaved_write_frame ()
Write_packet () really write data
ret = S->oformat->write_packet (s, PKT);
Write_packet here is a pointer defined in Avformat.h, pointing to Flv_write_packet ()

Follow the code in one step, discover the time-out control about network read and write, define in Url.h

struct/**< maximum time to wait for (network) Read/write ...} Urlcontext;

So in the initialization place, set this parameter:

LIBAVFORMAT/AVIO.C--->
Add the following statement before Url_alloc_for_protocol () return

Network read-write timeout control at 800ms

if (0800000)        UC800000;

Back to the project, the output time at both ends of the av_interleaved_write_frame, it is found that the interface in the network is not good, the basic control within 1s. Then it is not precise time control. Seemingly ffmpeg itself can not be strictly controlled to the millisecond level.

In order to ensure that this return must be answered, the LIBAVFORMAT/MUX.C
Modify the following code in Av_interleaved_write_frame ():

For

This uncontrolled for loop, instead

int  - ; int nn;  for (nn=0; nn<mouttimes;nn++)

The 128 here is an empirical value.

Av_interleaved_write_frame Exit slower