Does not stream with go2rtc rtsp authenication enabled

[luisiam]

trafficstars

Version of the custom_component

Frigate: 0.12.0-E8D8CC4 Integration: v4.0.0-beta4

Configuration

go2rtc:
  rtsp:
    username: "${FRIGATE_RTSP_USERNAME}"
    password: "${FRIGATE_RTSP_PASSWORD}"

Describe the bug

After enabling rtsp authentication in go2rtc, Home Assistant camera entity cannot stream. A bunch of authentication errors occur in the log. I am not using Frigate add-on within Home Assistant. Frigate is running as a separate docker.

Debug log

Logger: homeassistant.components.stream.stream.camera.backyard
Source: components/stream/__init__.py:434
Integration: Stream ([documentation](https://www.home-assistant.io/integrations/stream), [issues](https://github.com/home-assistant/home-assistant/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+stream%22))
First occurred: 7:49:36 PM (17 occurrences)
Last logged: 7:51:48 PM

Error from stream worker: Stream ended; no additional packets
Error from stream worker: Error opening stream (HTTP_UNAUTHORIZED, Server returned 401 Unauthorized (authorization failed)) rtsp://xxxxxxxxxxxx

[NickM-27]

If you're going to use authentication you need to use the rtsp templates to set that up

[luisiam]

The username and password are already in the RTSP template.

[NickM-27]

I'm referring to the template configuration in the integration in HA

[luisiam]

Yes, I am referring to that as well

[NickM-27]

Can you show how you set that up?

[luisiam]

The template is rtsp://user:password@ip:port/{{ name | lower}}

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cmsj]

I'm seeing this as well, I configured the RTSP template, but it doesn't seem like they are being used, so I'm unable to stream in Home Assistant.

[tpjanssen]

I'm struggling with this one as well. It looks like the template does not work. If set the "RTSP URL template" to e.g. "rtsp://127.0.0.1:8554/frontdoor", I would expect that all my camera's give the same image, but they don't.

It does not seem to make any difference what the value is set up to...

@NickM-27 can you please reopen this issue?

[NickM-27]

I don't have the powers here

[tpjanssen]

@blakeblackshear can you reopen this issue please?

The template does not seem to work. I'm using the latest beta, v5.0.0-beta.1.

[tpjanssen]

Thanks for reopening.

Any thoughts? Like I've mentioned, it seems the template is completely ignored.

[NickM-27]

haven't looked but the test passes without issues so not sure

https://github.com/blakeblackshear/frigate-hass-integration/blob/3cf97117d822fac6f1e071e19a090bca43b855cb/tests/test_camera.py#L368-L385

[NickM-27]

I'm struggling with this one as well. It looks like the template does not work. If set the "RTSP URL template" to e.g. "rtsp://127.0.0.1:8554/frontdoor", I would expect that all my camera's give the same image, but they don't.

important to note that the camera snapshots come from something different, so if you are simply opening each camera entity it may be showing the snapshot updating once a second and not actually opening the stream. I would not expect 127.0.0.1:8554 to work inside home assistant because 127.0.0.1 is localhost

[tpjanssen]

That's a good point, that might explain why I can't cast the camera entity to my Google TV?

Where is the RTSP template used for in that case?

[NickM-27]

That's a good point, that might explain why I can't cast the camera entity to my Google TV?

right, if the stream is not working then it can't be cast.

Where is the RTSP template used for in that case?

not understanding your question

[tpjanssen]

If I understand your post correctly... The camera.x entity by the integration is not a live feed to a RTSP stream, but a just a picture of the camery feed updating every second or so?

[NickM-27]

No, that is incorrect. It provides both a live stream and a snapshot that updates every second.

if the live stream is failing it will fall back to the auto updating snapshot

[tpjanssen]

My HA camera entity having these properties:

access_token: bed7b4a2e5795aef7b34fd16ffe7eb31e44a81912f84719f88a3755fdf55da
client_id: frigate
camera_name: achtertuin
restream_type: none
device_class: camera
entity_picture: /api/camera_proxy/camera.achtertuin?token=bed7b4a2e5795aef7b34fd16ffe7eb31e44a81912f84719f88a3755fdf55da
friendly_name: Achtertuin
supported_features: 0
motion_detection: true

When I change 127.0.0.1 to my actual IP address it is still now working. Like I said before, the doesn't seem to make any difference what I fill in...

[NickM-27]

restream_type: none

When I change 127.0.0.1 to my actual IP address it is still now working. Like I said before, the doesn't seem to make any difference what I fill in...

right, because it isn't even restreaming. This would be due to an issue in the frigate config

[tpjanssen]

A snippet from my Frigate config:

go2rtc:
  streams:
    achtertuin_record:
      - rtsp://admin:<redacted>@192.168.5.140:554/cam/realmonitor?channel=1&subtype=0
    achtertuin_detect:
      - rtsp://admin:<redacted>@192.168.5.140:554/cam/realmonitor?channel=1&subtype=2

cameras:
  achtertuin:
    mqtt:
      quality: 95
    ffmpeg:
      output_args:
        record: preset-record-generic-audio-copy
      inputs:
        - path: rtsp://127.0.0.1:8554/achtertuin_record
          input_args: preset-rtsp-restream
          roles:
            - record
        - path: rtsp://127.0.0.1:8554/achtertuin_detect
          input_args: preset-rtsp-restream
          roles:
            - detect
    detect:
      width: 1920
      height: 1080
      fps: 10
      stationary:
        interval: 50
        threshold: 50
    live:
      height: 720
      quality: 16
      stream_name: achtertuin_record
    record:
      enabled: True
      retain:
        days: 4
        mode: all
      events:
        pre_capture: 15
        post_capture: 15
        retain:
          default: 3
          mode: all
    snapshots:
      enabled: True
      bounding_box: True
      quality: 100
      retain:
        default: 21
        objects:
          bird: 3
    best_image_timeout: 1
    objects:
      track:
        - person
      filters:
        person:
          min_score: 0.58
          threshold: 0.78
    motion:
      contour_area: 15
      improve_contrast: True
      mask:
        - 1920,182,1625,64,1628,0,1920,0

What am I missing in that case?

[NickM-27]

there's the problem, none of the go2rtc streams match the name of the camera.

[tpjanssen]

That was my first assumption as well, that's why I configured the URL template to "rtsp://192.168.10.130:8554/{{name|lower}}_record". Without any effect though....

[NickM-27]

right, template can't be used to circumvent that requirement. The integration checks if a stream exists matching the entity name

[NickM-27]

also just in general wanted to say there is no reason to restream both main and sub stream unless you are actually using both of those outside of frigate, otherwise that is just wasted CPU cycles

[tpjanssen]

right, template can't be used to circumvent that requirement. The integration checks if a stream exists matching the entity name

If that's the case, can you give a usecase where the template is useful for?

also just in general wanted to say there is no reason to restream both main and sub stream unless you are actually using both of those outside of frigate, otherwise that is just wasted CPU cycles

Fair point. For now I use it this way because I'm preparing a second setup for 13.0 beta testing, and don't want two connections to camera directly.

[NickM-27]

If that's the case, can you give a usecase where the template is useful for?

I mean it would already work the usecase this issue is calling for, assuming the names match.

Template could work for that other case but the logic would need to be refactored

[tpjanssen]

I've renamed the stream, and now it's working. Thanks for your help!

I mean it would already work the usecase this issue is calling for, assuming the names match.

Template could work for that other case but the logic would need to be refactored

Not clear what you mean.... Do you mean that it should work as I assumed?

[NickM-27]

The integration would need new logic to work the way you had it before

[tpjanssen]

OK. Will this end up on a to do list? Or will the issue be forgotten?

Anyhow, my issue is solved. Thanks for all your efforts.