stopping the encoder drops the players stream at varying times before the rest of the feed should get there. Am I missing something in the cloudfront configuration maybe? I am using 2sec keyframe intervals in wirecast as an example and have not changed the LiveStreamPacketizer defaults from the guide to setting up cloudfront.
It’s not really possible for us to trouble-shoot the Cloudfront side. AWS pulls from the Wowza origin, so Wowza is not aware of how those chunks are stored, distributed or of any client connections. But it does make sense that there would be some variation.
Richard
Cloudfront aside, it is true that some players stop playback of live streams when the encoder is stopped, which seems to be because the RTMP notification sent by the encoder and on to each client (as NetStream.Play.UnpublishNotify) is taken as a signal to stop streaming, regardless of unplayed cache. The Wowza example players do not do this.
Richard
I understand that, Richard. But me setting up testing in a vanilla fashion, others must have noticed that this happens. I have not once had a stream finish playing the rest of the stream to the end after a live encoder stops.
I agree with Richard - this has been an issue with various streaming technologies and encoder/player combinations. I remember Windows Media Player stopping immediately after the encoder stopped when pushing the WMS data through Akamai - back in the old days…
So as a best practice we continue broadcasting a still image for a couple of minutes after the show ends. In times of 40+ seconds of HLS latency we tend to wait until the last player reached program end until we stop the encoders…