srs distribution of webrtc failed, the stream cannot be played

[luozhijunc]

Description
Configure SRS4 to pull RTSP stream (ingest RTSP) into SRS. SRS fails to distribute the stream via WebRTC, and WebRTC is unable to play the stream (it can be played using the RTMP protocol).

Description
Please describe the issue you are facing.

1. SRS Version: 4.0.23
2. SRS Configuration:
Based on the conf/rtc.conf file, add the following configuration for pulling streams:

vhost __defaultVhost__ {
    rtc {
        enabled     on;
        bframe      discard;
    }
	ingest livestream {
        enabled      on;
        input {
                type    stream;
                url     rtsp://admin:admin@192.168.1.108:554/cam/realmonitor?channel=1&subtype=1&unicast=true&proto=Onvif;
        }
        ffmpeg      ./objs/ffmpeg/bin/ffmpeg;
        engine {
                enabled          off;
                output          rtmp://192.168.1.206/live/stream;
        }
	}

}

Replay

1. Start SRS
2. Play webrtc://192.168.1.206/live/stream.
3. Unable to play WebRTC, but able to play RTMP.

Expected Behavior

Able to view streams through WebRTC

TRANS_BY_GPT3

[IIPoliII]

^^^ I think it's the same as my issue

[dean-river]

Try adding merge_nalus off; to the RTC configuration and see if it can play. It may be the same as mine.

TRANS_BY_GPT3

[IIPoliII]

@dean-river like that?

listen              1935;
max_connections     1000;
srs_log_tank        console;
srs_log_file        ./objs/srs.log;
daemon              off;

http_server {
    enabled         on;
    listen          8080;
    dir             ./objs/nginx/html;
}

http_api {
    enabled         on;
    listen          1985;
}
stats {
    network         0;
}
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;
    merge_nalus off;
}

vhost __defaultVhost__ {
    rtc {
        enabled     on;
        bframe      discard;
    }
}

because i still get the error :

[2020-04-28 01:53:19.821][Warn][11556][509][11] RTC error code=5020 : create session : stream /live/test busy
thread [11556][509]: do_serve_http() [src/app/srs_app_http_api.cpp:924][errno=11]
thread [11556][509]: create_rtc_session() [src/app/srs_app_rtc_conn.cpp:3176][errno=11]
[2020-04-28 01:53:19.918][Warn][11556][509][104] client disconnect peer. ret=1007

[dean-river]

Oh, you and mine are different. Mine doesn't have any error logs, but yours is throwing an error during the interactive SDP phase.

TRANS_BY_GPT3

[luozhijunc]

After adding "merge_nalus off;", we can play using WebRTC on this side.
Based on the configuration in "conf/rtc.conf".

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;
    merge_nalus off;
}

vhost __defaultVhost__ {
    rtc {
        enabled     on;
        bframe      discard;
    }
    ingest livestream {
        enabled      on;
        input {
                type    stream;
                url     rtsp://192.168.1.88/av0_0;
        }
        ffmpeg      ./objs/ffmpeg/bin/ffmpeg;
        engine {
                enabled          off;
                output          rtmp://192.168.1.206/live/stream;
        }
    }
}

TRANS_BY_GPT3

[wnpllrzodiac]

Testing found that the UDP packet reception in the local area network (LAN) environment is relatively stable. However, in the public network environment, there are a lot of negative acknowledgments (NACK). The video playback is limited to only one frame and freezes for several seconds. Is the UDP packet restricted by the internet service provider (ISP)? Or is the UDP packet size exceeding the maximum transmission unit (MTU) and being dropped?

TRANS_BY_GPT3

[wnpllrzodiac]

Took a look, there are still 12k big packages like this, I guess they were directly discarded from the public network...

1640
8776
518
520
26
520
78
523
11899

TRANS_BY_GPT3

[winlinvip]

@wnpllrzodiac SRS is divided into subpackages, with a maximum size of 1500. The 12k package you saw, did you capture it with Wireshark? Can you provide the Wireshark capture file?

TRANS_BY_GPT3

[wnpllrzodiac]

Sorry, I made a mistake. It's the total length that is so large. The individual packet sizes before that are normal.
This is a packet I captured on the server side, filtered out UDP.

TRANS_BY_GPT3

[wnpllrzodiac]

This is the UDP captured by the client in the local area network.

TRANS_BY_GPT3

[wnpllrzodiac]

The result of the public network test is very unstable.
I turned off NACK notification, otherwise the server logs keep showing NACK.
When playing the page, it takes more than 10 seconds to see one frame, and then it freezes for another 10 seconds.
The left side is the server's packet capture, and the right side is the client's packet capture. Except for the first UDP packet, the sizes don't match at all. I don't know where the data got messed up.

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       1.2.3.4 server public IP; #$CANDIDATE;
    #sendmmsg 1;
    #merge_nalus off;
}

vhost __defaultVhost__ {
    rtc {
        enabled     on;
        bframe      discard;
    }
    nack {
        enabled off;
    }
}

TRANS_BY_GPT3

[winlinvip]

Supporting NACK and TWCC is currently in progress, please refer to the official website History for more information. The program structure is currently being adjusted.
WebRTC is not as easy to handle as live streaming, so please be patient.

TRANS_BY_GPT3

[wnpllrzodiac]

@winlinvip Okay, thank you for your hard work!

In LAN mode, both the server and client's UDP packets are one-to-one.

TRANS_BY_GPT3