[FR] Transport stream type argument (rtsp_transport)

[alryaz]

Issue description

In short, I am having issues with acquiring TCP-only streams using ffmpeg.async_get_image(...) 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 extra_cmd argument to pass -rtsp_transport tcp through to ImageFrame.get_image(...) (subsequently - to HAFFmpeg.open(...)), however it gets put right after the input stream URL by an internal HAFFmpeg._generate_ffmpeg_cmd(...) 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_ffmpeg_cmd(...) 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 prefix_cmd argument to the HAFFmpeg._generate_ffmpeg_cmd(...), HAFFmpeg.open(...), ImageFrame.get_image(...), and to Home Assistant's own ffmpeg.async_get_image(...) 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.