deepch / RTSPtoWeb

RTSP Stream to WebBrowser
MIT License
1.27k stars 302 forks source link

Can't get docs/examples/webrtc/ code to work - says stream not found #302

Open jacksnodgrass opened 1 year ago

jacksnodgrass commented 1 year ago

I have RTSPtoWeb installed and running. I can see my camera feed using http://127.0.0.1:8083 and selecting my camera feed.

http://127.0.0.1:8083/streams responds with:

{
    "status": 1,
    "payload": {
        "27aec28e-6181-4753-9acd-0456a75f0289": {
            "channels": {
                "0": {
                    "status": 1,
                    "url": "rtsp://user:pass@10.12.15.230/live"
                }
            },
            "name": "birdcam"
        }
    }
}

the docs/examples/webrtc/index.html code has: ( I used the 'birdcam' stream link.. I think that's entered correctly....

<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>RTSPtoWeb WebRTC example</title>
  </head>
  <body>
    <h1>RTSPtoWeb WebRTC example</h1>

    <input type="hidden" name="webrtc-url" id="webrtc-url"
        value="http://127.0.0.1:8083/stream/birdcam/channel/0/webrtc">

    <video id="webrtc-video" autoplay muted playsinline controls
        style="max-width: 100%; max-height: 100%;"></video>

    <script src="main.js"></script>
  </body>
</html>

but RTPStoWeb shows:

ERRO[2023-03-04T17:16:51-06:00] stream not found call=StreamChannelExist channel=0 func=HTTPAPIServerStreamWebRTC module=http_webrtc stream=birdcam

I am not sure what the correct value for the webrtc-url variable is based off of the http://127.0.0.1:8083/streams output.

I think that: http://127.0.0.1:8083/stream/birdcam/channel/0/webrtc would be correct... but the error indicates otherwise.

I am trying to show the output of my camera on a HTML5 page....

awdm commented 1 year ago

According to the API Docs, the WebRTC call signature is

http://127.0.0.1:8083/stream/{STREAM_ID}/channel/{CHANNEL_ID}/webrtc

So try http://127.0.0.1:8083/stream/27aec28e-6181-4753-9acd-0456a75f0289/channel/0/webrtc (assuming the GUID from your post is still the correct one).

jacksnodgrass commented 1 year ago

Still not working... This works: http://127.0.0.1:8083/ and I can see my camera and see the webrtc link on that widget... http://127.0.0.1:8083/pages/player/webrtc/27aec28e-6181-4753-9acd-0456a75f0289/0 and that gets me to a web page with the video playing in it... but just trying to see JUST the video so I can display it on my own html5 page trying: http://127.0.0.1:8083/stream/27aec28e-6181-4753-9acd-0456a75f0289/channel/0/webrtc gets me to a web page that just says: 404 page not found . . . so the API docs do say: http://127.0.0.1:8083/stream/{STREAM_ID}/channel/{CHANNEL_ID}/webrtc should work... but it does not appear to be working... so here we are....

awdm commented 1 year ago

I assume you are also using the main.js file from the example? Do you get any errors on your browser console?

allenporter commented 1 year ago

You can't take a webrtc stream url and stick it in the browser, it needs the JavaScript. That webrtc end point is posting an rdp description so it's not a valid way to test the url.

lawrence-jeff commented 1 year ago

@deepch - Lots of confusion on the WebRTC links and the expectation they work as is in a browser - would it be possible if you do a get request to one that it replies with something clarifying like - "This URL can't be used directly in a browser but it does appear to be a valid stream URL" (assuming it is).

allenporter commented 1 year ago

I recommend looking at https://github.com/deepch/RTSPtoWeb/tree/master/docs/examples and https://webrtc.org/getting-started/overview for generally understanding how WebRTC works.

lawrence-jeff commented 1 year ago

I don't understand your reply - I was agreeing with your point above To quote you: You can't take a webrtc stream url and stick it in the browser, it needs the JavaScript. That webrtc end point is posting an rdp description so it's not a valid way to test the url.

Since this seems like a common confusion, I was recommending instead of the just replying with a 404, it could reply with basically your quote with maybe a pointer to the proper instructions to avoid this common source of confusion. It would probably cut down on issues/requests for help