When pushing RTMP and playing RTC, the app stream received by HTTP hooks is inconsistent.

[xupeng1206]

Note: Before asking a question, please read the FAQ (Please read FAQ before filing an issue) #2716

Description

When the streaming address is in the format of rtmp://dev-stream.turingvideo.cn:1935/live/436/387236c7d1f4112c4b7d9580cdb047f0, the app and stream received in the data of on_connect, on_play, and on_stop are inconsistent when playing with webrtc.

In on_connect, app=live and stream=436/387236c7d1f4112c4b7d9580cdb047f0.

In on_play and on_stop, app=live/436 and stream=387236c7d1f4112c4b7d9580cdb047f0.

1. SRS version (Version): 4.0-Release.

2. The log of SRS is as follows (Log):
   

3. The configuration of SRS is as follows (Config):

# main config for srs.
# @see full.conf for detail config.

listen              1935;
max_connections     10000;
srs_log_tank        console;
daemon              off;
http_api {
    enabled         on;
    listen          1985;
}
http_server {
    enabled         on;
    listen          8080;
    dir             ./objs/nginx/html;
}
stats {
    network         0;
    disk            sda sdb xvda xvdb;
}
rtc_server {
    enabled         on;
    # Listen at udp://8000
    listen          8000;
    #
    # The $CANDIDATE means fetch from env, if not configed, use * as default.
    #
    # The * means retrieving server IP automatically, from all network interfaces,
    # @see https://github.com/ossrs/srs/issues/307#issuecomment-599028124
    candidate       $CANDIDATE;
}
vhost __defaultVhost__ {
    tcp_nodelay     on
    min_latency     on;

    hls {
        enabled         off;
    }
    http_remux {
        enabled     on;
        mount       [vhost]/[app]/[stream].flv;
    }
    rtc {
        enabled     on;
        bframe      discard;
        rtmp_to_rtc on;
        rtc_to_rtmp off;
    }
    play {
        gop_cache       off;
        queue_length    10;
        mw_latency      0;
    }

    publish {
        mr off;
        # mr_latency 100;
        normal_timeout 600000;
    }

    http_hooks{
        enabled       on;
        # 172.18.0.3 => srs_hook container ip
        on_connect    http://172.18.0.3:8085/api/srs/hooks/connect;
        on_close      http://172.18.0.3:8085/api/srs/hooks/close;
        # on_publish    http://172.18.0.3:8085/api/srs/hooks/publish;
        # on_unpublish  http://172.18.0.3:8085/api/srs/hooks/unpublish;
        on_play       http://172.18.0.3:8085/api/srs/hooks/play;
        on_stop       http://172.18.0.3:8085/api/srs/hooks/stop;
        # on_dvr        http://172.18.0.3:8085/api/srs/hooks/dvr;
        # on_hls        http://172.18.0.3:8085/api/srs/hooks/hls;
        # on_hls_notify http://172.18.0.3:8085/api/srs/hooks/hls_notify;
    }
}

Replay

How to replay bug?

Steps to reproduce the bug

Steps to reproduce the bug:

1. Use ffmpeg to push the stream to an address like rtmp://dev-stream.turingvideo.cn:1935/live/436/387236c7d1f4112c4b7d9580cdb047f0.
2. Play the stream using webrtc, with the playback address: webrtc://dev-stream.turingvideo.cn/live/436/387236c7d1f4112c4b7d9580cdb047f0.
3. Check the SRS logs to reproduce the issue.

Expected behavior:

Expected behavior:

Expect the app, stream, and other information to be consistent during rtmp push and rtc playback in on_connect, on_play, and on_stop.

TRANS_BY_GPT3

[xupeng1206]

Try to fix it yourself: #2798
Not sure if the changes are correct.

TRANS_BY_GPT3

[winlinvip]

According to our simplified definition, we only support multi-level apps, not multi-level streams.

If the URL is:

rtmp://dev-stream.turingvideo.cn:1935/live/436/387236c7d1f4112c4b7d9580cdb047f0

Then it should be:

schema: rtmp
host: dev-stream.turingvideo.cn
port: 1935
app: live/436
stream: 387236c7d1f4112c4b7d9580cdb047f0

It is equivalent to our belief that directories can have multiple levels, while files do not support multiple levels.

TRANS_BY_GPT3

[xupeng1206]

According to our simplified definition, we only support multi-level apps and do not support multi-level streams.

If the URL is:

rtmp://dev-stream.turingvideo.cn:1935/live/436/387236c7d1f4112c4b7d9580cdb047f0

Then it should be:

schema: rtmp
host: dev-stream.turingvideo.cn
port: 1935
app: live/436
stream: 387236c7d1f4112c4b7d9580cdb047f0

It means that we believe directories can have multiple levels, while files do not support multiple levels.

If that's the case, then the PR I mentioned earlier would be problematic. I'll wait for the API expert to take a look. Thank you.

TRANS_BY_GPT3

[duiniuluantanqin]

Test with the URL you provided, on_connect/play/stop, the app and stream are the same. And as the author said, the app supports hierarchy, while the stream does not. So your PR may not be merged.

TRANS_BY_GPT3

[xupeng1206]

Test with the URL you provided, on_connect/play/stop, the app and stream are the same. And as the author said, the app supports hierarchy, while the stream does not. So your PR may not be merged.

Sorry for the inconvenience, I tested again just now. In the on_connect function, I still get app=live and stream=123/uuid. According to the design, it should be app=live/123 and stream=uuid. There seems to be a discrepancy between the result and the design. I tested with the latest code from the 4.0 Release, commit 0dd6246 @duiniuluantanqin.

TRANS_BY_GPT3

[winlinvip]

Unable to reproduce the issue you mentioned, for example, the app is live/live, and the stream is livestream.

SRS configuration:

    http_hooks {
        enabled         on;
        on_connect      http://127.0.0.1:8085/api/v1/clients;
        on_publish      http://127.0.0.1:8085/api/v1/streams;
    }

Streaming:

ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://localhost/live/live/stream

SRS Log:

client identified, type=fmle-publish, vhost=localhost, app=live/live, stream=stream, param=, duration=0ms

Callback Log:

srs on_connect: vhost=__defaultVhost__, app=live/live, tcUrl=rtmp://localhost:1935/live/live, pageUrl=

srs on_publish: vhost=__defaultVhost__, app=live/live, stream=stream, param=

TRANS_BY_GPT3

[xupeng1206]

Unable to reproduce the issue you mentioned, for example, the app is live/live, and the stream is livestream.

SRS configuration:

    http_hooks {
        enabled         on;
        on_connect      http://127.0.0.1:8085/api/v1/clients;
        on_publish      http://127.0.0.1:8085/api/v1/streams;
    }

Push streaming:

ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://localhost/live/live/stream

SRS log:

client identified, type=fmle-publish, vhost=localhost, app=live/live, stream=stream, param=, duration=0ms

Callback log:

srs on_connect: vhost=__defaultVhost__, app=live/live, tcUrl=rtmp://localhost:1935/live/live, pageUrl=

srs on_publish: vhost=__defaultVhost__, app=live/live, stream=stream, param=

• Thank you to all the teachers for their time. In the end, it was found that the streaming tool was the cause. After changing the version of ffmpeg and streaming, it matched the description provided by the author.

TRANS_BY_GPT3

[winlinvip]

Thank you for confirming and providing feedback, @xupeng1206.

Thank you, Haibo, for investigating together, @duiniuluantanqin.

TRANS_BY_GPT3