We have setup WebRTC according to:
https://www.wowza.com/docs/how-to-use-webrtc-with-wowza-streaming-engine and that is working fine.
We are testing with the Wowza test publish page: https://www.wowza.com/_private/webrtc/4.7.4/publish/
When we start a WebRTC stream, we only want to support incoming video codec H264 and audio codec Opus. This way, there is only need to transcode the audio codec from opus to aac. The video codec should not be changed, as it is already H264. This is setup in Wowza as preferred codecs.
So we create a new transcoder profile, where we transcode the audio to AAC and use video ‘passthrough’ option. This will save a lot of CPU/GPU power in transcoding.
So far this all works on all browsers except Safari on iOS and Safari on the Mac. There the video starts to freeze after x seconds or x minutes. It looks like there is an issue with keyframes. Because the chunks are still being downloaded an audio is still playing. But there is no update of the image.
So then we enabled video transcoding to H264 codec with all the default options enabled. That means a baseline profile and a video bitrate of 1Mbps. Then the interesting part comes to play. Keyframes!
Then we select the option ‘Same as source (required for transrating)’ at ‘Key frame interval’ or at specific amount of frames. Then it is all working stable. But this means that the video stream has to be transcoded from h264 to h264 only to get the keyframes in the stream. This sounds strange. I would expect that when you ingest webrtc in H264, that could be used without transcoding for HLS.
We use the Apple HLS inspector tool https://developer.apple.com/documentation/http_live_streaming/hls_authoring_specification_for_apple_devices#2969490 to inspect the HLS streams. As there are some issues according to this tool the main difference between transrating vs passtrough is that there are no key frames in the passtrough stream. And the stream is hanging.
Therefore we conclude at this time, that WebRTC to HLS does not provide keyframes. But interesting is that when you select ‘Same as source (required for transrating)’ there is a key frame every second. So it looks like there are keyframes sent with WebRTC, as the transcoder is adding them every second based on the WebRTC input stream (if I have to belief that wowza is doing that based on the key frames choice).
Now we are looking to find a way that video transcoding is not needed to get it stable on Safari with HLS. How can we make sure that keyframes from the WebRTC are used in the HLS stream?
To be clear, we do NOT use WebRTC for watching. We only use WebRTC for ingest. Watching is done in HLS. So the following issues looks related, but are about watching back in WebRTC. Could it be that somehow some video meta data is being sent in the HLS chunks also that is causing the freezes? And that the transcoder does strip it and make it more stable?
https://www.wowza.com/community/questions/48772/webrtc-transcoded-streams-freeze.html
https://www.wowza.com/community/questions/47213/h264-stream-freezes-ios-safari.html
So is there anybody with a smart solution for this? Wowza team?
