By using AWS re:Post, you agree to the Terms of Use

Basic IVS Channel Type: delay before playback starts

0

Standard IVS channels begin playback instantly. Basic IVS channels seem to take up to 15 seconds to start playing. Why is this? Is this a bug at your end? I'm using videojs, but am encountering the same behaviour no matter what I use to playback streams. EDIT: For clarification, I'm not talking about the time it takes for the stream to be accessible after recording begins, I'm talking about the time it takes for playback to start at ANY point during the stream.

1 Answers
1

Hi, thank you for using the Amazon Interactive Video Service. Based on the information provided, the aforementioned "delay" behavior has not been observed before. One test that could be completed is to test the behavior using the IVS managed debug player (https://debug.ivsdemos.com/?p=vjs&url=https://fcc3ddae59ed.us-west-2.playback.live-video.net/api/video/v1/us-west-2.893648527354.channel.DmumNckWFTqz.m3u8&d=&l=debug). After loading this webpage, the browser console logs can be opened (using right-click and "Inspect"). The debug console view will show any error/warning messages shown when trying to load the basic channel for playback. To load your own content into the debug player, the playback URL of your channel can be placed in the text box labeled "Playback URL..."

For a more in depth investigation into the channels and their properties, please reach out to AWS Support: https://console.aws.amazon.com/support

answered 4 months ago
  • I've used the managed debug player. Here is the output from the Standard (which take 0.5 seconds to start playing) and the Basic (which takes about 5 seconds to start playing in that particular instance): https://www.dropbox.com/scl/fo/s0msfw2n5yqaut5j9y7fh/h?dl=0&rlkey=bbwqmkmllj4oilukhqbb6ipxe I'd appreciate it if an AWS tech could look at this as it definitely seems like there's a bug in the way that Basic streams are delivered from your end here. I will also say, that the Standard almost always takes the same amount of time to start playing, whereas the Basic varies significantly.

  • Thank you for the debug logs. For an additional test, can you complete the same test with the following playback URL: https://a7de2931d765.us-west-2.playback.live-video.net/api/video/v1/us-west-2.552568312991.channel.ollGhov7I5ho.m3u8 This URL will be active for the next 4 days, following the post of this comment. The playback URL provided above is of a Basic channel that has ideal broadcast/encoder settings, thus it will help us (the IVS team) narrow down where the root cause of the issue is potentially occurring.

    Additionally, it is worth noting that the distribution of content for standard and basic channels are the same, thus there is likely no issues with the delivery of content, but rather a root cause at the broadcasting or playback side. After numerous tests, the IVS service team has not been able to reproduce the behavior being seen and thus are asking for the above test to understand where the root cause of the behavior may reside.

    As mentioned above as well, if you would like a more in depth investigation into the behavior, we would highly recommend reaching out to AWS Support: https://console.aws.amazon.com/support

  • Thanks for that! The playback from that stream link that you've sent is perfect. I've managed to figure out the cause of the problem with Basic streams: the keyframe interval. If this is set to 8s or above, the problem occurs, below this and it's fine. I previously had the keyframe interval in OBS set to auto, which I believe usually sets it to around 8.5 seconds - hence having the problem. Interestingly, with standard streams, I can set the keyframe interval to the maximum in OBS (20s) and it still doesn't encounter the problem.

  • To add to my previous comment, is there a reason why this behaviour occurs with only the Basic streams? I would like my users to not have to worry about messing around with the keyframe interval settings and make it more foolproof. If there's something that could be changed to fix this at your end, that would be great!

  • Thank you for the update and we are glad to hear that the behavior has been resolved by changing the keyframe interval. To answer the question on why this occurs on basic channel streams (and does not occur on standard channel streams) is that it is a result of how the stream is processed. Basic channel streams are transmuxed (not re-encoded by IVS), where as standard channel streams are transcoded (https://docs.aws.amazon.com/ivs/latest/userguide/ivs-glossary.html). The standard channel transcoding process is completed by IVS and is seemingly fixing the incompatible keyframe interval set by the source encoder.

    The IVS team strongly recommends a keyframe interval of 2 seconds (https://docs.aws.amazon.com/ivs/latest/userguide/streaming-config.html#streaming-config-settings). While there is an understanding that it can be difficult to have all broadcasters adhere to the IVS recommendations, there are unintended/unexpected behaviors that come from using settings outside those recommended. As you observed, IVS still functions (albeit with a greater latency) when a keyframe interval of 8 seconds or greater is set. However, it does not function to the full capability of ultra-low latency streaming. Seeing as all streamers/broadcasters may have various reasons for different keyframe interval values, IVS is not able to enforce a 2 second keyframe interval on their end.

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