SRS whep https pull stream failed

[191474639]

!!! Before submitting a new bug report, make sure you have asked the AI about your issue, because we have setup the project with docs for AI, so AI know everything including questions, usage, bugs, features, workflows, etc.

rtmp
A clear and concise description of what the bug is.

Version
7.

To Reproduce
Steps to reproduce the behavior:

1. rtmp push
2. Click on '....' pull
3. rtmp2.conf
   max_connections 1000;
   daemon off;
   srs_log_tank console;
   rtmp {
   listen 1935;
   }

http_server {
enabled on;
listen 8080;
dir ./objs/nginx/html;
https {
enabled on;
listen 8443;
key /opt/srs/trunk/data/test.paly.yaojingw.top.key; # 此处有修改
cert /opt/srs/trunk/data/test.paly.yaojingw.top.pem; # 此处有修改
}

}

http_api {
enabled on;
listen 1985;
https {
enabled on;
listen 1990;
key /opt/srs/trunk/data/test.paly.yaojingw.top.key;
cert /opt/srs/trunk/data/test.paly.yaojingw.top.pem;
}
}
stats {
network 0;
}
rtc_server {
enabled on;
listen 8000; # UDP port
# @see https://ossrs.io/lts/en-us/docs/v7/doc/webrtc#config-candidate
candidate 36.1xx.195.xx;
}

vhost defaultVhost {
rtc {
enabled on;
# @see https://ossrs.io/lts/en-us/docs/v7/doc/webrtc#rtmp-to-rtc
rtmp_to_rtc on;
# @see https://ossrs.io/lts/en-us/docs/v7/doc/webrtc#rtc-to-rtmp
rtc_to_rtmp on;
}
http_remux {
enabled on;
mount [vhost]/[app]/[stream].flv;
}
}
5. See error
Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

[191474639]

rtmp://36.134.1xx.xx/live/livestream?secret=b35cb0d49f714f28b5697f1da4e6a3b9,then https pull failed

[suzp1984]

where is the srs log? and the web console's log maybe?

[winlinvip]

Truth Record — 2026-08-01

• Verified branch: forge
• Verified commit: 6d2a5c5c37642025d25939b740abaa8e069689c6
• Verified version: SRS 8.0.4
• Reported version: SRS 7; exact revision was not provided
• Verification environment: macOS 26.5.2, arm64
• Verification method: Complete issue discussion, screenshot, project documentation, source code, and history review
• Runtime reproduction: Not required; the submitted URLs establish the mismatch directly
• Project changes and tests: None
• Supersedes: None

Reported behavior

The report publishes the RTMP stream live/livestream with an additional query parameter, but requests WHEP playback using:

/rtc/v1/whep/?app=live&stream=livestream.flv

The screenshot confirms that exact WHEP URL and shows no received media.

Verified current behavior

SRS parses the RTMP publishing query separately from the stream name. The published stream name is therefore livestream.

The WHEP handler reads the stream query parameter verbatim. It does not remove media-container suffixes. Consequently, stream=livestream.flv requests a different stream named livestream.flv, which does not match the published stream livestream.

The correct WHEP URL is:

https://server:1990/rtc/v1/whep/?app=live&stream=livestream

The .flv suffix is only appropriate for HTTP-FLV playback through the HTTPS HTTP server, for example:

https://server:8443/live/livestream.flv

The project WebRTC and getting-started documentation already show WHEP URLs without .flv. The submitted HTTPS configuration is supported, and the available evidence does not indicate an HTTPS implementation failure.

Conclusion

This is not an SRS bug. It is a user-side URL misuse: an HTTP-FLV-style .flv suffix was added to the WHEP stream name, causing the publisher and player to use different stream names.

The correct usage is already documented and can also be obtained from the SRS project AI. This report does not justify a code, documentation, knowledge-base, or skill update.

Close the issue as a usage error with no project change.

Remaining unknowns

The exact SRS 7 revision and requested diagnostic logs were never provided. They do not change the confirmed stream-name mismatch. If the corrected WHEP URL still fails, a new report should include the exact version, SRS logs, browser console/WebRTC diagnostics, and candidate/UDP reachability evidence.