MediaLive input loss behavior triggered by still images in stream

Yes, as noted in the question, the InputVideoFrameRate (CloudWatch dashboard) does appear to drop when this problem happens in the still image portion of the stream, so that is a reasonable hypothesis. I don't know how to make OBS (or is it really libx264?) preserve the frame rate. Thanks for the tip about channel logging which I can try to see if it sheds any light.

Here are channel log entries when problem occurs (I am excluding log entries about failure to connect to a Facebook Destination that I know is not properly configured so these are noise)

First when problem occurs:

2022-07-09 19:09:51.000 {"channel_arn": "arn:aws:medialive:us-west-2:434221060529:channel:3565940", "encoder_pipeline": 0, "logger_name": "", "message": "Setting alert [5101] [1.1] [5101-1.1] [[1.1] Audio not detected: Check input signal]", "severity": "W", "timestamp": "2022-07-09T19:09:51.997116"} 2022-07-09 19:09:51.000 {"channel_arn": "arn:aws:medialive:us-west-2:434221060529:channel:3565940", "encoder_pipeline": 0, "logger_name": "", "message": "Setting alert [5101] [2.1] [5101-2.1] [[2.1] Audio not detected: Check input signal]", "severity": "W", "timestamp": "2022-07-09T19:09:51.997218"} 2022-07-09 19:09:50.000 {"channel_arn": "arn:aws:medialive:us-west-2:434221060529:channel:3565940", "encoder_pipeline": 0, "logger_name": "", "message": "Setting alert [5302] [sam://localhost:5030/eth2] [5302-sam://localhost:5030/eth2] [Stopped receiving network data on [sam://localhost:5030]]", "severity": "W", "timestamp": "2022-07-09T19:09:50.287563"}

Then 8 seconds later these alerts clear, with continuity errors, but don't seem to be able to put enough text in this comment. There is mention of SDT data not received. The still image is sent for longer than this, and loss detection drops out and restores stream after some seconds while still image remains the output.

I have found reference to say that MediaConnect suppresses null packets which "can result in a fluctuating bitrate on the subscriber's flow, or a difference between the bitrate of the content originator's flow and the subscriber’s flow". Could it be that MediaConnect is suppressing null packets sent when image is not changing in video stream? Also, OBS stats show no indication of FPS dropping from OBS during such test.

Thank you Steve. I had already configured key frame interval to 2 in OBS.

If you are referring to the video that shows force-cfr=1, I spent a lot of time going down this road without success. The specific instructions in that video generate an error message from OBS today (and don't make sense since x264 is not a muxer AFAICT), but I translated this into video encoder settings with error message guidance and it did not help. libx264 clearly does have this parameter (I see it in the source) but hard to confirm it is actually getting set by OBS, and if so it did not make a difference. I will try to repeat this test to be sure. OBS live stats do not show any decline in frame rate with this problem, though I have seen a decline in other circumstances on different machine (GPU contention I believe) so it can show up there.

Also have started looking at file write of sample encode (rather than transmission to AWS) and it does not appear that there are null packets included in the first place when still image is presented.

Thanks for the suggestion - I have not tried that because I have had trouble with SRT to another service. Congestion on our Internet service is what pushed me to try RIST after SRT could not handle it well either. The RIST test here went really well, except for this anomaly with some stills. My last test with force-cfr was a little inconclusive: it was not completely successful but things were better, and one failure might have been unrelated rendering loss. We're trying yet another service in meantime.