MediaLive input loss behavior triggered by still images in stream

0

I have been testing livestreaming with MediaLive to YouTube and Facebook and in the course of the stream we occasionally put up still images (e.g. some text for audience to read, or photographs to view) which is causing MediaLive to invoke the Input Loss Behavior - we get black or repeated frame (as configured) and lose audio though we are sending continual audio throughout.

On CloudWatch I am able to see InputVideoFrameRate drops that appear to correlate.

Changing the channel general settings Global Configuration to Support Low Framerate Inputs = ENABLED seems to have helped greatly. With this the problem is avoided sometimes but other times we still lose audio behind the repeated frame for a few seconds before it resumes.

Input path is from OBS Studio via RIST to MediaConnect to MediaLive using SINGLE_PIPELINE rather than STANDARD.

Is there any way to avoid MediaLive detecting still images in a stream as input loss?

jdt
asked 2 years ago513 views
4 Answers
0

OK. The next thing to check is the

InputVideoFrameRate

metric for your channel. This can be seen in the health tab of the channel detail page, or in CloudWatch metrics. Does it drop during the still image portion of your stream? If so OBS is varying the frame rate of the stream, which can cause problems if MediaLive is expecting a fixed frame rate source. You can also enable logging in the channel config (General Settings -> Channel Logging) which when set to WARNING, INFO, or DEBUG (least verbose to most) may provide useful insight into what is causing the input loss detection.

Regards, Steve

AWS
Steve_W
answered 2 years ago
  • 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.

0

Hi jdt,

Check and see if you have configured a key frame interval in OBS. 2 seconds is a common value to use. What may be happening is if you use the default configuration "Auto" then OBS may slow the key frame interval during the still image portion of your stream.

Regards, Steve

AWS
Steve_W
answered 2 years ago
  • Thank you Steve. I had already configured key frame interval to 2 in OBS.

0

Stripping null packets from the stream is a feature of several protocols, including RTMP and Zixi, so I don't think that's the issue here. I was able to find some references online to OBS continuing to use VFR even when configured with a fixed frame rate, including a video clip illustrating the flags needed to be passed to x.264 in order to force it to maintain CFR. I used the search terms "obs constant frame rate" for this search.

AWS
Steve_W
answered 2 years ago
  • 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.

0

It might be worth trying SRT to MediaConnect instead of RIST to see if it is something unique to that protocol.

AWS
Steve_W
answered 2 years ago
  • 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.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions