bugfix: SrsAsyncCallWorker::cycle to crash

[bluestn]

    dvr {
        # the filter for dvr to apply to.
        #       all, dvr all streams of all apps.
        #       <app>/<stream>, apply to specified stream of app.
        # for example, to dvr the following two streams:
        #       live/stream1 live/stream2
        # default: all
        dvr_apply       all;
    }

[winlinvip]

I checked the situation where trd is NULL in SrsAsyncCallWorker::cycle, and it only occurs when DvrPlan is being deleted.

SrsDvrPlan::~SrsDvrPlan()
{
    srs_freep(async);
}

SrsAsyncCallWorker::~SrsAsyncCallWorker()
{
    srs_freep(trd);
}

When DvrPlan stops, it will have a stop and clean task, which will cause a switch.

void SrsDvrPlan::on_unpublish()
{
    async->stop();
}

void SrsAsyncCallWorker::stop()
{
    flush_tasks();
    srs_cond_signal(wait);
    trd->stop();
}

In combination with the reload of dvr_apply, the above logic will be triggered frequently.

srs_error_t SrsDvr::on_reload_vhost_dvr_apply(string vhost)
{
    SrsConfDirective* conf = _srs_config->get_dvr_apply(req->vhost);
    bool v = srs_config_apply_filter(conf, req);
    
    on_unpublish();
    
    if ((err = on_publish()) != srs_success) {
        return srs_error_wrap(err, "on publish");
    }
}

So the problem should be in this place. To be determined specifically.

TRANS_BY_GPT3

[winlinvip]

A more suitable solution:

1. dvr_apply does not support reload, so we can support it through the HTTP API by recording different streams.
2. Move SrsDvrPlan.async to the global scope to avoid each Plan having its own asynchronous worker, thus preventing frequent opening and closing of workers.

I mentioned a new issue: #2181.

TRANS_BY_GPT3

[winlinvip]

Still need to thank @bluestn for the Pull Request.

TRANS_BY_GPT3