FFmpeg: open stream and read stream timeout design

ffmpeg's avformat? Open? Input() and AV? Read? Frame are blocked by default

* the user can set "IC - > flags | = avfmt 〝 flag 〝 Nonblock;" as non blocking (usually not recommended);

* or set the timeout;

* or set interrupt call to define the return mechanism.

Design of opening time-out

The main point of attention is to pay attention to the agreement

 timeout:(http:ms udp:s)

 stimeout:(rtsp us)

1. Set rtsp timeout

AVDictionary* opts = NULL;

av_dict_set(&opts, "rtsp_transport", m_bTcp ? "tcp" : "udp", 0); //Set tcp or udp. By default, tcp takes precedence and then tries udp

av_dict_set(&opts, "stimeout", "3000000", 0);//The unit us is 3s

ret = avformat_open_input(&ctx, url, NULL, &opts);

2. Set udp,http timeout

AVDictionary* opts = NULL;

av_dict_set(&opts, "timeout", "3000000", 0);//Unit: http:ms, udp:s

int ret = avformat_open_input(&ctx, url, NULL, &opts);


Read stream timeout design

1. Method of callback

//Set the callback after opening successfully, and monitor the read timeout. In this way, you can modify it dynamically

    context->ifmt_ctx->interrupt_callback.opaque = (void*)context;

    context->ifmt_ctx->interrupt_callback.callback = interruptCallback;//Set callback

//Record the start time before each stream read

context->read_start_time = time(NULL);

int ret = av_read_frame(context->ifmt_ctx, &pkt);

//Callback monitoring

static int interruptCallback(void *context){

    ACCHLSContext *ctx = (ACCHLSContext *)context;//ACCHLSContext is my custom structure, which is set by callback opaque

    if (ctx == NULL) {

        return 0;

    }

    ACCUInt64_t end =  time(NULL);

    if (end - ctx->read_start_time >= 3) {

        return 1;

    }

    return 0;

}

2. Parameter setting

//It can't be set dynamically. It can only be set before opening the flow

AVDictionary* opts = NULL;

av_dict_set(&opts, "rw_timeout", "3000", 0);//Unit: ms

int ret = avformat_open_input(&ctx, url, NULL, &opts);


Note: when I am doing HLS live streaming and on-demand broadcasting, because the m3u8 file on demand is generated in real time, in theory, it is 3s to generate a file, but if the network is not good, this time will be very long.

If you follow this design, it's easy to time out. But if the setting time is too long, it is easy to jam the thread when shutting down. So my approach is: in addition to this timeout design, add another design. If the continuous read stream fails for 25s, the external timeout disconnection will be notified.

I don't know if there is any other good way. Welcome to communicate with me

Tags: network

Posted on Sun, 03 May 2020 06:56:41 -0400 by kabucek