We’re writing code that processes the raw H264 video frames and seeing some odd behavior when the RTMS app is paused, then resumed. Trying to determine if this is an issue with our code or if it is inherent to how the H264 video stream works.
The stream works by sending keyframes which are independent and non-keyframes which are dependent on an earlier keyframe. When the RTMS app is paused, then resumed, will the Zoom server send a keyframe as soon as it is resumed? Or is it possible that you’ll send a non-keyframe which references a keyframe that we could not have received because it was sent when the app was paused?
@chunsiong.zoom @michael.zoom
1 Like
@noah.duncan are you trying to do recording RTMS?
@noah.duncan there will be a keyframe sent when the video resumes. Some considerations when doring recording is that you will need to pad the “muted” video part with your own place holder vide, such as empty black h264 video frames.
Are there any issues which you have encountered on recording?
We have recently improved network performance of the RTMS video to prevent dropped frames, do test and let me know if you enounter any issues. Do tag me in your response as well
1 Like
Hey @chunsiong.zoom
We are currently padding the paused part with black frames.
However, we are not seeing a keyframe come in immediately after the video resumes, so we are forced to keep padding with black frames even though the video has been resumed. It usually takes a few seconds for us to get a keyframe after the video has been resumed, which lets us show the video.
Here is a video of our RTMS recording which shows the behavior: https://drive.google.com/file/d/1s-fJ5Rk72JRxj7CnkWn8tRqJUEM1bh1I/view?usp=sharing
@noah.duncan thanks for the video, I’ll get back to you on this
@noah.duncan I have some updates on this. I’ve checked with the team and the keyframe is delivered at a fixed interval. The pausing and resuming does not forces an adhoc keyframe.
Thanks for flagging this, we will be putting this as a feature to work on.
2 Likes