Failed to get the playlist (#default#app/bypass_stream/) because there is no available rendition

[aukuste]

Before asking for help, please read the troubleshooting section in the manual carefully. https://airensoft.gitbook.io/ovenmediaengine/troubleshooting

Please fill out the form below to create an issue. Failure to follow the form may result in late responses or close issues.

PROBLEM

When trying to view a stream with OvenPlayer I get a few error messages when OvenPlayer tries to connect to OvenMediaEngine. See below for logs.

I really don't understand what the issue is.

EXPECTATION

OvenPlayer should be displaying the stream.

ENVIRONMENTAL INFORMATION

• OvenMediaEngine Information OvenMediaEngine version: 0.15.1

Q: What encoder are you using?(e.g. OBS 10.22) And how is the codec set on that encoder? A: OBS 29.0.0. Video formats and such can be seen in the logs below.

• Player information OvenPlayer version: 0.10.25

Q: Please tell me which address you used to send and play. You can hide IP or Domain. A: wss://DOMAIN.TLD:3334/app/bypass_stream?policy=POLICY&signature=SIGNATURE

• Operating system and version

Q: Please tell me the OS and version (e.g. Ubuntu 20.04) A: Ubuntu 20.04.5

SETUP INFORMATION AND LOGS

Server configuration: Server.txt

Server log when trying to view the stream (annotated with comments detailing what is happening when the log lines are showing up. Look for lines that start and end with #####): log.txt

OvenPlayer config: ovenplayer.txt

[getroot]

Thanks for reporting. What OS/browser are you using for playback? This issue is not reproducible in my environment. This can happen if your browser does not support the H.264 codec for WebRTC playback. I never expected that there would be such a browser.

It will be more helpful in analyzing the problem if you copy and upload the SDP sent by the browser like the screen I captured.

"v=0\r\no=- 2716378638463289966 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE WJbj3v aVF5U2\r\na=msid-semantic: WMS\r\nm=video 9 UDP/TLS/RTP/SAVPF 98\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:PjV8\r\na=ice-pwd:/TRAlxrPwvKeLS/QOPJ1taHG\r\na=ice-options:trickle\r\na=fingerprint:sha-256 D0:E8:51:5F:FE:11:CF:60:00:5C:29:6C:C4:53:13:5D:2D:68:26:47:E0:F9:B4:37:AA:0A:62:A3:D3:FE:25:C4\r\na=setup:active\r\na=mid:WJbj3v\r\na=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=recvonly\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=rtpmap:98 H264/90000\r\na=rtcp-fb:98 goog-remb\r\na=fmtp:98 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f\r\nm=audio 9 UDP/TLS/RTP/SAVPF 110\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:PjV8\r\na=ice-pwd:/TRAlxrPwvKeLS/QOPJ1taHG\r\na=ice-options:trickle\r\na=fingerprint:sha-256 D0:E8:51:5F:FE:11:CF:60:00:5C:29:6C:C4:53:13:5D:2D:68:26:47:E0:F9:B4:37:AA:0A:62:A3:D3:FE:25:C4\r\na=setup:active\r\na=mid:aVF5U2\r\na=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=recvonly\r\na=rtcp-mux\r\na=rtpmap:110 OPUS/48000/2\r\na=fmtp:110 minptime=10;useinbandfec=1;stereo=1\r\n"

[aukuste]

I'm running Fedora Linux 37 (with an NVIDIA GPU). Using Firefox 109.0.

Your comment about this being something that can happen when your browser doesn't support h264 is certainly quite interesting, so I tried playing the stream using Chromium 108.0.5359.124 and that worked without any issues.

But anyway, here's the SDP sent by Firefox to the server:

v=0o=mozilla...THIS_IS_SDPARTA-99.0 7485505961479511790 0 IN IP4 0.0.0.0s=-t=0 0a=fingerprint:sha-256 2C:44:C1:7B:C1:C6:52:9E:B1:1D:FA:D3:69:1E:E5:B1:9C:EC:2A:DA:20:9D:A8:36:60:5A:CB:BC:0E:EC:1B:EEa=group:BUNDLE Pe9pHGa=ice-options:tricklea=msid-semantic:WMS *m=video 0 UDP/TLS/RTP/SAVPF 120c=IN IP4 0.0.0.0a=inactivea=mid:y4k9cda=rtpmap:120 VP8/90000m=audio 9 UDP/TLS/RTP/SAVPF 110c=IN IP4 0.0.0.0a=recvonlya=fmtp:110 maxplaybackrate=48000;stereo=1;useinbandfec=1a=ice-pwd:89fbe210777d73c0800d96beb4a3ac4fa=ice-ufrag:6ee5f8a9a=mid:Pe9pHGa=rtcp-muxa=rtpmap:110 opus/48000/2a=setup:activea=ssrc:3024072046 cname:{6976b704-bd44-45d0-80a3-737dd21ec5f4}

And here is the SDP sent by Chromium:

v=0\r\no=- 2329292743054014404 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE y4k9cd Pe9pHG\r\na=msid-semantic: WMS\r\nm=video 9 UDP/TLS/RTP/SAVPF 98\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:ruCJ\r\na=ice-pwd:8tZeuCvVLkd0lPlemfSv0H/R\r\na=ice-options:trickle\r\na=fingerprint:sha-256 31:E3:D6:86:CD:27:22:A9:FD:17:F6:31:6F:CB:39:BE:CF:2C:95:B6:12:24:6E:9C:8A:46:55:D0:F3:66:D9:12\r\na=setup:active\r\na=mid:y4k9cd\r\na=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=recvonly\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=rtpmap:98 H264/90000\r\na=rtcp-fb:98 goog-remb\r\na=fmtp:98 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f\r\nm=audio 9 UDP/TLS/RTP/SAVPF 110\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:ruCJ\r\na=ice-pwd:8tZeuCvVLkd0lPlemfSv0H/R\r\na=ice-options:trickle\r\na=fingerprint:sha-256 31:E3:D6:86:CD:27:22:A9:FD:17:F6:31:6F:CB:39:BE:CF:2C:95:B6:12:24:6E:9C:8A:46:55:D0:F3:66:D9:12\r\na=setup:active\r\na=mid:Pe9pHG\r\na=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=recvonly\r\na=rtcp-mux\r\na=rtpmap:110 OPUS/48000/2\r\na=fmtp:110 minptime=10;useinbandfec=1;stereo=1\r\n

These are the settings I use in OBS for streaming to test things out right now:

I wonder if there's something wrong with OvenPlayer that doesn't see that Firefox has h264 support, or if there's something wrong with Firefox on Fedora that doesn't report h264 support correctly? Gonna test out Flatpak Firefox.

[aukuste]

Nevermind with the Flatpak version. Apparantly you need to install some extra packages to enable h264 over WebRTC on Fedora ( https://docs.fedoraproject.org/en-US/quick-docs/openh264/ ) in Firefox.

Unbelievable.

Thank you very much for solving the issue here. It didn't occur to me at all to test with another browser. God knows how many hours I've spent on this changing the config around for the server.

[getroot]

Yes, your fedora firefox doesn't support H.264. "m=video 0 UDP/TLS/RTP/SAVPF 120c=IN IP4 0.0.0.0a=inactive" says it. It seems that only VP8 is supported.

To play on your fedora firefox you will need to enable VP8 encoding in OME's Server.xml.

[getroot]

One tip is setting the keyframe interval to 0 can slow down the initial playback. It is recommended to set it to 1 or 2.

[aukuste]

Thank you for the tip :)

[hashworks]

I've the same error with a similar setup.

Config: Server.xml The config contains an OutputProfile with a playlist for multiple video options, one for a bypass and two for h264 transcodes. Nginx terminates the TLS of the signaling server.

This accepts a RTMP stream and creates some video tracks:

Transcoder | filter_rescaler.cpp:166  | Rescaler is enabled for track #0 using parameters. input: video_size=2560x1440:pix_fmt=0:time_base=1/1000:pixel_aspect=1/1 / outputs: fps=fps=30.00:round=near,scale=1280x720:flags=bilinear,settb=1/90000
Transcoder | filter_rescaler.cpp:166  | Rescaler is enabled for track #0 using parameters. input: video_size=2560x1440:pix_fmt=0:time_base=1/1000:pixel_aspect=1/1 / outputs: fps=fps=30.00:round=near,scale=1920x1280:flags=bilinear,settb=1/90000
MediaRouter | mediarouter_application.cpp:380  | [#default#live/foo(3527953265)] Stream has been prepared
[Stream Info]
id(3527953265), msid(0), output(foo), SourceType(Transcoder), RepresentationType(Source), Created Time (Tue Mar 21 21:03:37 2023) UUID(b39c8dad-7c67-4655-9705-bd5b04db94b2/default/#default#live/foo/o)
        >> Origin Stream Info
        id(100), output(foo), SourceType(Rtmp), Created Time (Tue Mar 21 21:03:36 2023)

        Video Track #0: Public Name(Video_0) Variant Name(bypass_video) Bitrate(12.83Mb) Codec(1,H264,Passthrough) BSF(H264_AVCC) Resolution(2560x1440) Framerate(64.94fps) KeyInterval(0) BFrames(0) timebase(1/1000)
        Video Track #1: Public Name(Video_0) Variant Name(video_1280) Bitrate(5.02Mb) Codec(1,H264,OpenH264) BSF(H264_ANNEXB) Resolution(1920x1280) Framerate(30.00fps) KeyInterval(0) BFrames(0) timebase(1/90000)
        Video Track #2: Public Name(Video_0) Variant Name(video_720) Bitrate(2.02Mb) Codec(1,H264,OpenH264) BSF(H264_ANNEXB) Resolution(1280x720) Framerate(30.00fps) KeyInterval(0) BFrames(0) timebase(1/90000)
        Audio Track #3: Public Name(Audio_1) Variant Name(bypass_audio) Bitrate(351.15Kb) Codec(6,AAC,Passthrough) BSF(AAC_RAW) Samplerate(48.0K) Format(fltp, 32) Channel(stereo, 2) timebase(1/1000)
        Audio Track #4: Public Name(Audio_1) Variant Name(audio_0) Bitrate(128.00Kb) Codec(8,OPUS,libopus) BSF(OPUS) Samplerate(48.0K) Format(s16, 16) Channel(stereo, 2) timebase(1/48000)
        Data  Track #5: Public Name(Data_2) Variant Name(Data) Codec(0,Unknown,Passthrough) BSF(ID3v2) timebase(1/1000)
WebRTC Publisher | rtc_stream.cpp:192  | WebRTC Stream has been created : foo/3527953265
Rtx(false) Ulpfec(false) JitterBuffer(false) PlayoutDelay(false min:0 max: 0)
Publisher | stream.cpp:204  | WebRTC Publisher Application application has started [foo(3527953265)] stream (MSID : 0)

Loading a player with wss://example.net/live/foo works fine and uses the bypass, but as soon as I request the playlist with wss://example.net/live/foo/abr I get the same error, but using a different browser (Arch Firefox/Chromium, Windows Firefox, Windows Chrome) doesn't fix it:

Signalling | rtc_signalling_server.cpp:315  | New client is connected: <ClientSocket: 0x7f8766f54810, #26, Connected, TCP, Nonblocking, 127.0.0.1:53112 (host: '')>
WebRTC Publisher | rtc_session.cpp:155  | Failed to get the playlist (#default#live/foo/abr) because there is no available rendition
WebRTC Publisher | webrtc_publisher.cpp:448  | Cannot create session for (#default#live/foo/abr)
Signalling | rtc_signalling_server.cpp:410  | An error occurred while dispatch command answer for stream [#default#live/maker]: [HTTP] Forbidden (403), disconnecting...

The same happens when I try to transcode to vp8.

Arch Firefox WSS messages:

Server:

{
    "candidates": [
        {
            "candidate": "candidate:9174805236 1 UDP 50 10.64.161.196 10005 typ host",
            "sdpMLineIndex": 0
        },
    ],
    "code": 200,
    "command": "offer",
    "iceServers": [
        {
            "credential": "airen",
            "urls": [
                "turn:ipv4:53478?transport=tcp",
            ],
            "username": "ome"
        }
    ],
    "ice_servers": [
        {
            "credential": "airen",
            "urls": [
                "turn:ipv4:53478?transport=tcp",
            ],
            "user_name": "ome"
        }
    ],
    "id": 787773083,
    "peer_id": 0,
    "sdp": {
        "sdp": "v=0\r\no=OvenMediaEngine 148 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE DMfghW\r\na=msid-semantic:WMS dTZ1YMRDyI59fgH2ueiU0sjzhS8JP4EQWxrq\r\na=fingerprint:sha-256 22:DD:12:75:ED:78:CB:18:BE:59:21:AB:B5:49:1A:68:02:60:FC:B0:32:BE:64:B9:17:F0:7E:2E:CF:CC:46:E5\r\na=ice-options:trickle\r\na=ice-ufrag:fZruV9\r\na=ice-pwd:wJ4m0eQuq7CWrONdg3ZLFoPE9zVRTSvY\r\nm=video 9 UDP/TLS/RTP/SAVPF 98 96\r\nc=IN IP4 0.0.0.0\r\na=sendonly\r\na=mid:DMfghW\r\na=setup:actpass\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=msid:dTZ1YMRDyI59fgH2ueiU0sjzhS8JP4EQWxrq g1r8y2RwdkBHo4e7LWhp5K3UVcFu6QsJ9XjC\r\na=extmap:1 urn:ietf:params:rtp-hdrext:framemarking\r\na=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=rtpmap:98 H264/90000\r\na=fmtp:98 packetization-mode=1;profile-level-id=42e01f;level-asymmetry-allowed=1\r\na=rtcp-fb:98 goog-remb\r\na=rtpmap:96 VP8/90000\r\na=rtcp-fb:96 goog-remb\r\na=ssrc:3957801563 cname:dTuWvtjsNgEAa9Y1\r\na=ssrc:3957801563 msid:dTZ1YMRDyI59fgH2ueiU0sjzhS8JP4EQWxrq g1r8y2RwdkBHo4e7LWhp5K3UVcFu6QsJ9XjC\r\na=ssrc:3957801563 mslabel:dTZ1YMRDyI59fgH2ueiU0sjzhS8JP4EQWxrq\r\na=ssrc:3957801563 label:g1r8y2RwdkBHo4e7LWhp5K3UVcFu6QsJ9XjC\r\n",
        "type": "offer"
    }
}

Browser:

{
    "id": 787773083,
    "peer_id": 0,
    "command": "answer",
    "sdp": {
        "type": "answer",
        "sdp": "v=0\r\no=mozilla...THIS_IS_SDPARTA-99.0 8826687915330327178 0 IN IP4 0.0.0.0\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 C6:9D:3D:DB:2F:B4:59:40:65:81:D4:9F:E1:24:C8:7C:6D:4F:73:2F:2C:82:C6:AD:64:16:C2:C2:15:50:56:05\r\na=group:BUNDLE DMfghW\r\na=ice-options:trickle\r\na=msid-semantic:WMS *\r\nm=video 9 UDP/TLS/RTP/SAVPF 98 96\r\nc=IN IP4 0.0.0.0\r\na=recvonly\r\na=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=fmtp:98 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1\r\na=fmtp:96 max-fs=12288;max-fr=60\r\na=ice-pwd:83239b46ce6572cd8d482ca3913347d4\r\na=ice-ufrag:6df2c1b4\r\na=mid:DMfghW\r\na=rtcp-fb:98 goog-remb\r\na=rtcp-fb:96 goog-remb\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=rtpmap:98 H264/90000\r\na=rtpmap:96 VP8/90000\r\na=setup:active\r\na=ssrc:2317019103 cname:{e8ffdcee-6e34-4adc-8547-efa8e168ba54}\r\n"
    }
}

Server:

{"code":403,"error":"Forbidden"}

Any idea?

[hashworks]

So yeah, the error is because the client supports none of the provided renditions: Not because of the video codec, but because WebRTC supports no AC3 (so there has to be a redition with OPUS).

It would be great if OME had a better error message for that case.