hls slice is incorrect

[suoc]

srs3.0 Latest
When watching flv live stream, CPU usage is full, HLS slicing is abnormal, unable to watch

TRANS_BY_GPT3

[winlinvip]

Fixed, issues caused by sleep units.

TRANS_BY_GPT3

[suoc]

It will still cause slicing abnormalities. The slices will gradually decrease until each slice is reduced to 6-8K, making it impossible to watch.

TRANS_BY_GPT3

[winlinvip]

How to replay it?

[suoc]

1. Complex handshake success: RTMP streaming, such as this, will have abnormal slicing.
2. Simple handshake success: In this case, there will be no abnormal slicing, everything is normal.

The second type is OBS streaming, while the first type is a stream pushed by a hardware encoder.

TRANS_BY_GPT3

[suoc]

A develop version around March 19, 2017 does not have any slicing issues. However, all subsequent versions have them. Please take a look at what changes have been made.

TRANS_BY_GPT3

[winlinvip]

Please provide the steps to reproduce, including detailed configuration and operating steps.

TRANS_BY_GPT3

[suoc]

It should not be a configuration issue. I think the problem might be with the streaming from the hardware encoder. It's difficult to reproduce this issue. Can you provide me with the address of your server? I will push the stream to your server.

The configuration of the hardware encoder is as follows:

bitrate control : cbr
key interval : 30
encoded size : 1280`*`720
bitrate : 2500
fluctuate level : auto
h.264 profile : main profile
encoding frame rate : 25
Package: ffmpeg (or vlc)
buffer mode : 188`*`7

======srs.conf======

listen 1935;
max_connections 1000;
srs_log_tank file;
srs_log_file ./objs/srs.log;
http_api {
    enabled on;
    listen 1985;
    crossdomain on;
    raw_api {
        enabled on;
        allow_reload on;
        allow_query on;
        allow_update on;
    }
}
http_server {
    enabled on;
    listen 8090;
    dir ./objs/nginx/html;
    crossdomain off;
}
stats {
    network 0;
    disk sda sdb xvda xvdb;
}
stream_caster {
    enabled off;
    caster rtsp;
    output rtmp://127.0.0.1/[app]/[stream];
    listen 8554;
    rtp_port_min 57200;
    rtp_port_max 57300;
}
vhost __defaultVhost__ {
    http_remux {
        enabled on;
        fast_cache 30;
        mount [app]/[stream].flv;
    }
    hls {
        enabled on;
        hls_path ./objs/nginx/html;
        hls_fragment 10;
        hls_window 60;
    }
    dvr {
        enabled on;
        dvr_apply none;
        dvr_plan session;
        dvr_path /home/live/[app]/[stream]/mp4/[2006]/[01]/[02]/[stream].[timestamp].mp4;
        dvr_duration 30;
        dvr_wait_keyframe on;
        time_jitter full;
    }
}

TRANS_BY_GPT3

[winlinvip]

After recording an FLV using srs_rtmp_dump, you can use ingest to collect this FLV for SRS and check if there are any issues with the resulting HLS. If there are any problems, please send me the FLV file to my email.

TRANS_BY_GPT3

[suoc]

Already sent to winlin at vip.126.com

TRANS_BY_GPT3

[suoc]

Have you found the reason?

Currently, the slice will continue to gradually decrease.

TRANS_BY_GPT3

[gotomypc]

This problem is quite complicated, mainly reaching the following code interval.

        // reuse current segment index.
        _sequence_no--;
        
        srs_trace("Drop ts segment, sequence_no=%d, max_td=%d,  uri=%s, duration=%" PRId64 "ms", current->sequence_no, max_td, current->uri.c_str(), current->duration());
        
        // rename from tmp to real path
        if ((ret = current->unlink_tmpfile()) != ERROR_SUCCESS) {
            return ret;
        }
        srs_freep(current);

TRANS_BY_GPT3

[johnwang777]

The time for calculating audio packet in these two places is inconsistent, resulting in the duration increasing until it is dropped, which has nothing to do with whether to watch the FLV or not.

The simple solution is to set dts = audio->timestamp * 90; in SrsHls::on_audio. That's how it works.

int SrsHlsMuxer::flush_audio(SrsTsMessageCache* cache)
{
.....
// update the duration of segment.
current->append(cache->audio->pts / 90);
.....
}

int SrsHls::on_audio(SrsSharedPtrMessage* shared_audio, SrsFormat* format)
{
.......
// Recalc the DTS by the samples of AAC.
int64_t dts = 90000 * aac_samples / srs_flv_srates[format->acodec->sound_rate];
aac_samples += nb_samples_per_frame;

if ((ret = controller->write_audio(format->audio, dts)) != ERROR_SUCCESS) {
    srs_error("hls cache write audio failed. ret=%d", ret);
    return ret;
}

return ret;

}

TRANS_BY_GPT3

[winlinvip]

@johnwang777 Calculating HLS timestamps directly based on RTMP will result in audio distortion issues. Please refer to #547 (comment) for more information.

TRANS_BY_GPT3

[winlinvip]

Fixed.