0.81.0b0 FFmpeg Camera Test Fails (Xiaomi Xiaofang)

[mynameisdaniel32]

Home Assistant release with the issue:
0.81.0b0

Last working Home Assistant release (if known):
0.80.3

Operating environment (Hass.io/Docker/Windows/etc.):
Linux Debian (venv)

Component/platform:
FFmpeg Camera

Description of problem:
Since updating to 0.81.0b0, one of my FFmpeg cameras fails to start, no changes to the config and my other FFmpeg camera works as it did.

It looks like something is causing a test to fail based on the error log below.

The camera I'm using is a Xiaomi Xiaofang running custom firmware to enable an RTSP stream (which works).

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

ffmpeg:
  ffmpeg_bin: /usr/bin/ffmpeg

camera:
  - platform: ffmpeg
    input: -rtsp_transport tcp -i rtsp://10.10.2.149/unicast
    name: Carport
    extra_arguments: -pred 1 -q:v 2

  - platform: ffmpeg
    input: -rtsp_transport tcp -i rtsp://10.10.3.148:8554/unicast
    name: Front Yard
    extra_arguments: -pred 1 -q:v 2

Traceback (if applicable):

2018-10-22 11:33:34 ERROR (MainThread) [homeassistant.components.ffmpeg] FFmpeg '-rtsp_transport tcp -i rtsp://10.10.2.149/unicast' test fails!

Additional information:

[akinomeroglu]

I am using a Dafang camera with a cfw and I can repeat the problem too.

[keirans]

I have 2 cameras using the above configuration and both are non functional in 0.81.0 on hassio.

No changes on the camera side, and both RTSP feeds are OK via VLC.

[edif30]

I found that this is due to this change - #17609

As soon as I reverted it, issue went away. I was also getting seg faults due to timeouts of this coroutine.

[bieniu]

Same issue with HA 0.81.1.

[edif30]

@jjlawren you ok with me submitting a PR to revert the await in the coroutine for ffmpeg? Or do you want to?

[jjlawren]

@edif30 please make a PR, I won't be able to until tomorrow. Perhaps I'm not seeing this new behavior as I was testing out changes involving skipping tests in #17769 at the same time. Sorry for causing problems for anyone, it seemed like a trivial change to fix the warning in the original PR description.

@pvizeli any suggestions on a proper fix?