what happens is that the bitrate that is getting measured at the edge is being used for the tag in the m3u8 which the player reads from.
since live video encodings usually fluctuates a bit if we measure the bitrate by second but the GOP is multiple seconds it really as you said might be different to your average bitrate.
I will take that as a feature request to force the bitrate for the playlist files or to have the bitrate being measured by average bitrate of 1 GOP and not current second or peak.
Would you please let me know what the weird viewing behavior was you were seeing caused by this?
It would be great to have a short chat to better understand what stream target types you were using.
Thanks for letting me know.
Thanks for your response. I have an open case on this now - #193801, and have just submitted some of my configuration files. The artifacts and corruption I was seeing might have been limited to the Wowza Player. When targeting the Player at a cloud-transcoded stream, it works fine. When targeting it at a CDN passthrough, it would work briefly. but then unusual artifacts and the stream would eventually hang. Other players, such as Bitmovin, might have still been working fine - but I’ll have to go and check. I chose to utilize the preview player because I liked the ability to customize the messages when the stream wasn’t available. I’m not sure if the invalid bitrate is related to the corruption in the player or not, but it was the first thing I noticed, so thanks for explaining.