Onvif integration (new type) ignores rtsp_transport protocol settings

[Saur0o0n]

The problem

New automated Onvif integrations ignores rtsp_protocol settings - to be exact - does not forward it to ffmpeg. It's set properly in configuration file - but somehow it's lost during invoking ffmpeg module

:~/.homeassistant/.storage$ grep tcp *
core.config_entries:                    "rtsp_transport": "tcp"

Environment

It's cleaned up configuration (after using onvif platform and onvif2 custom module). HA is 0.113.3 It's standalone installation with pip

Traceback/Error logs

It doesn't matter if I set it to UDP or TCP - ffmpeg switch '-rtsp_transport tcp' is not being set up:

:~/.local/lib/python3.8/site-packages/homeassistant/components/onvif$ ps -ef |grep ffmpeg
hassio   2006467 1997142  5 10:36 pts/4    00:00:00 ffmpeg -i rtsp://admin:pass@192.168.70.35:554/live/ch0 -an -frames:v 1 -c:v mjpeg -pred 1 -f image2pipe -
hassio   2006474 1997826  0 10:36 pts/12   00:00:00 grep ffmpeg

[probot-home-assistant[bot]]

Hey there @hunterjm, mind taking a look at this issue as its been labeled with an integration (onvif) you are listed as a codeowner for? Thanks! _{^{(message by CodeOwnersMention)}}

[Saur0o0n]

Hi, Any update on this issue? I guess the new Onvif integration is missing much more then simple rtsp_transport. There should be also (or at least it would be "nice to have") a way to add some camera specific arguments to ffmpeg - per camera not onvif wide. In my case this is rtsp, but also some cameras fail to respond in proper time - and hit timeout value. Dirty workaround is to modify "haffmpeg.core" - this work in my case to add global rtsp=tcp and lower probesize

hassio@sauron:~$ grep -B4 rtsp .homeassistant/deps/lib/python3.8/site-packages/haffmpeg/core.py
        extra_cmd: Optional[str] = None,
    ) -> None:
        """Generate ffmpeg command line."""
        self._argv = [self._ffmpeg]
        self._argv.extend(["-rtsp_transport", "tcp", "-probesize", "64"])

[hunterjm]

The RTSP transport option is for setting the configuration of the stream component: https://github.com/home-assistant/core/blob/dev/homeassistant/components/onvif/camera.py#L81-L83

You would use the "Extra FFMPEG Arguments" option to set -rtsp_transport tcp to be passed in as part of the input for haffmpeg... along with any other arguments. These are camera specific, since each ONVIF integration is for a specific device. If that device is an NVR, the NVR is re-routing the camera stream through it, and Home Assistant is not connecting directly to the camera.

[hunterjm]

The docs should probably be updated to reflect the purpose of "RTSP transport mechanism" properly. https://www.home-assistant.io/integrations/onvif/#extra-configuration-of-the-integration

[Saur0o0n]

Two month ago I've migrated from configruation.yml defined Onvif to UI Integration Onvif - because it stoped working with custom_component onvif2 - that had defined all (working) ptz settings. So long story short, now I have default Onvif, defined by Integration in UI. I've changed back and forth TCP to UDP (on screen you've just posted) - it has completely no effect on ffmpeg invocation. And this is what I've reported in initial post. And this is what I've showed as "ps".

Since this completely brakes my cameras, I've tried to find workaround. I've made shell script with "ffmpeg -rtsp_transport tcp $@" - and substituted it for ffmpeg binary - this works, but only for static images, streaming doesn't work. My today's workaround is because I'm not fluent enough in python code - but this is harmless for any other tasks that ffmpeg could perform (unless it involves rtsp :) ). I would definitely prefer it to be fixed properly at ha-onvif module.

Mentioned "Extra ffmpeg arguments" are applied after source stream - so won't work. It has to be before "-i" parameter. And finally - those extra arguments are global to all onvif cameras - not the best solution either.

[andriej]

@Saur0o0n what exactly is your workaround right now as I didn't get that? I have the same problem, so UDP stream camera that is configured as TCP despite any setting in HA.

[Saur0o0n]

@Saur0o0n what exactly is your workaround right now as I didn't get that? I have the same problem, so UDP stream camera that is configured as TCP despite any setting in HA.

I've made permanent change to ffmpeg invocation - so every time it is called with TCP. It doesn't brake anything this way, unless you have some camera (I don't) that requires UDP. I've described it here: https://github.com/home-assistant/core/issues/38506#issuecomment-693344087

There is additional line "self._argv.extend(["-rtsp_transport", "tcp", "-probesize", "64"])". Probesize is there to shorten start time.

[Saur0o0n]

After all the new releases (currently 2020.12.01) - this issue is still not fixed/resolved.

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.