RTMP data channel caues ffmpeg analyzeduration very slow.

[zh19900725]

Note: Please read FAQ before file an issue, see #2716

Description

The srs develop branch is used here, and it was found that the initial loading of RTMP is always particularly slow. After troubleshooting, it was found that this is because there is always an extra channel in RTMP, but this channel does not output. Looking at the ffpmeg source code, it will cause analyzeduration to be stuck in a loop until it reaches the maximum value, which makes the initial loading particularly slow.

1. SRS Version: develop

2. SRS Config:

listen              2035;
max_connections     10000
srs_log_level       trace;
# For log rotation, you need to install the logrotate plugin: https://ossrs.net/lts/zh-cn/docs/v5/doc/log-rotate
pid                  /data/logs/srslog/srs.pid;
ff_log_dir           /data/logs/srslog;
srs_log_file         /data/logs/srslog/srs.log;

http_api {
    enabled         on;
    listen          9008;
    crossdomain     on;
}

heartbeat {
    enabled         on;
    interval        9.3;
    url             http://XXXX/invoke/heartbeat?env=0;
    device_id       "srs1";
    summaries       off;
}

rtc_server {
    enabled on;
    listen 443;
    tcp {
        enabled on;
        listen 443;
    }
    protocol tcp;
    candidate *;
}

http_server {
    enabled         on;
    listen          9008;
    dir             /run/media;
}

vhost __defaultVhost__ {
    tcp_nodelay     on;
    min_latency     on;

    play {
        gop_cache       off;
        queue_length    10;
        mw_latency      100;
    }

    publish {
        mr off;
    }
    hls {
        enabled         on;
        hls_path        /run/media;
        hls_fragment    4;
        hls_window      10;
    }

    rtc {
        enabled on;
        nack on;
        twcc on;
        stun_timeout 30;
        dtls_role passive;
        rtmp_to_rtc on;
        rtc_to_rtmp off;
    }

    http_remux {
        enabled     on;
    }

    http_hooks {
        enabled        on;
        on_hls         http://XXXX/invoke/onHls?env=0;
        on_play        http://XXXX/invoke/onPlay?env=0;
        on_unpublish   http://XXXX/invoke/onUnPublish?env=0;
        on_publish     http://XXXX/invoke/onPublish?env=0;
        on_stop        http://XXXX/invoke/onStop?env=0;
    }
}

Replay

This is a recurring issue. After deployment, pulling RTMP can reproduce it, there will be an extra channel which is Stream #0:0: Data: none, and an error will be reported below: Unsupported codec with id 0 for input stream 0.

Expect

Do not affect the analyzeduration, let it quickly complete the analysis and return the data. I know many people would say that it's fine to reduce this time, but this requires constraints on the playback end, and many times, constraining others is uncontrollable.

TRANS_BY_GPT4

[laurfb]

Hi. All version (v4, v5, v6 develop) output a default, null, data stream, beside the video and audio streams. And, indeed, some players cannot identify/play corectly such RTMP streams. ffmpeg always identify that extra stream as Data (#0:0). But ffplay can play it! While Larix Player (https://play.google.com/store/apps/details?id=com.softvelum.sldp_player) cannot play such streams. Or some (Magewell, Datavideo) hardware decoder/players.

regards, Laur

[zh19900725]

Hello. All versions (v4, v5, v6 development) output the default empty data stream next to the video and audio streams. In fact, some players cannot correctly recognize/play such RTMP streams. ffmpeg always identifies this extra stream as data (#0:0). However, ffplay can play it! But Larix Player ( https://play.google.com/store/apps/details?id=com.softvelum.sldp_player ) cannot play such streams. Or some hardware decoders/players (like Melewei, Datavideo).

Greetings, Raul

It's a bit strange, I found that with the audio on, even if the analyzeduration is set to 5s, it will quickly finish analyzing and start rendering and playing. But if there is no audio, the analyzeduration will keep looping until it stops after 5s and starts playing.

TRANS_BY_GPT4

[zh19900725]

Okay. All versions (v4, v5, v6 development) output the default empty data stream next to the video and audio streams. In fact, some players cannot correctly recognize/play such RTMP streams. ffmpeg always prompts you to attach the stream identifier as data (#0:0). However, ffplay can play! But Larix Player (https://play.google.com/store/apps/details?id=com.softvelum.sldp_player) cannot play such streams. Some or (Meloway, Datavideo) hardware decoders/players.

Greetings, Raul

Please advise, how did you solve this problem? This issue affects the analysis of analyzeduration. In fact, it can be solved by reducing the analyzeduration on the playback side (this has been verified with ffplay), but there are too many playback sides in production, it's impossible to ask them all to make changes.

TRANS_BY_GPT4

[laurfb]

Hi. No solution for now. :( Even remuxed rtmp stream from srt (with "srt_to rtmp on;" option) got an extra (null) data stream. As you can see the primarly srt stream have only video (#0:0) and audio (#0:1). Remux code add an extra data stream (#0:0) changing also the final stream internal order (audio #0:1, video #0:2). Don't know if that (extra null data stream and order change) broke decoding in some cases. Please find bellow two screenshots with ffmpeg outputs (original srt and remuxed rtmp stream). regards, laur

[nguyencobap]

Any solution ?, I don't want to add -analyzeduration

[nguyencobap]

I found solution: add "atc on;" to play configuration:

play {
    # your other config here

    atc on;
}

Here is why in srs document:

With this option I can play rtmp without have to wait. But http_remux still error.

[winlinvip]

Generally, an RTMP stream includes a video stream, an audio stream that represents audio, and an optional data stream that contains AMF0 metadata. The data stream should be generated by your encoder, however I think we can disable it if make FFmpeg stuck. Need more research about the source of the data channel.

BTW: I believe the HLS streaming does not have this bug, because HLS protocol doesn't incorporate the concept of AMF0 data. Both RTMP and HTTP-FLV should have this bug.