[FR] Transport stream type argument (rtsp_transport)

[alryaz]

Issue description

In short, I am having issues with acquiring TCP-only streams using _ffmpeg.async_getimage(...) from Home Assistant. The issue lies within the difference between the following commands:

This one works: ffmpeg -rtsp_transport tcp -i '<stream_url>' -an -frames:v 1 -c:v mjpeg -f image2pipe - This one does not work: ffmpeg -i '<stream_url>' -an -frames:v 1 -c:v mjpeg -f image2pipe - And this one does not work, either: ffmpeg -i '<stream_url>' -rtsp_transport tcp -an -frames:v 1 -c:v mjpeg -f image2pipe -

I tried using the _extracmd argument to pass -rtsp_transport tcp through to _ImageFrame.getimage(...) (subsequently - to HAFFmpeg.open(...)), however it gets put right after the input stream URL by an internal _HAFFmpeg._generate_ffmpegcmd(...) call, whereas it is required to be put in front of it (I am unaware why, however this is a solution I have stumbled upon while trying to debug a component I am working on).

To combat this, I have prepared a really shoddy diversion (see: my __init__.py of the pik_intercom integration), which monkey-patches the _HAFFmpeg._generate_ffmpegcmd(...) method to generate a working request. I abstained from using a valid rtsp_transport argument in favor of a virtual input_rtsp_transport argument as not to break anything for any of my users.

Feature proposal

My proposal would be to add an extra _prefixcmd argument to the _HAFFmpeg._generate_ffmpegcmd(...), HAFFmpeg.open(...), _ImageFrame.getimage(...), and to Home Assistant's own _ffmpeg.async_getimage(...) component method.

I may make pull requests to both repositories to implement the issue in question, however I am not well-acquainted with the library.