We’re getting: “Ending the current a+v chunk although the chunk does not start with a video keyframe” in the logs but I cannot find anything about that particular message anywhere in the forums or docs. What does this mean and how do we clear this message for good?
Hello @Terry Longordo, I will check into this message for you.
Thank you so much. We’re standing by.
Our engineers say it is a newish log message @Terry Longordo. You would normally see it on the first chunk where the packetizer started on something other than a key frame. It may affect playback for the first players, but once it’s flushed then there shouldn’t be a problem.
I’m still checking to see if there is a way to clear it for good.
Thank you for your help but I am still not getting what this means. It’s a newish log message, doesn’t quite help me understand what it means nor its implications. So as you search for a way to clear it, may I request a better description of the cause? Thanks again, I eagerly await your response.
Thank you for letting me know it’s still unclear. Let me get a more detailed descriptions for you @Terry Longordo.
Are you still getting this message in the logs @Terry Longordo? We do not have a solution on how to remove it. I requested a deeper explanation of the cause and will check again for that. Sorry for the delay…
The answer I received for you @Terry Longordo
HLS chunks that contain video are normally supposed to always start on keyframes to allow seamless switching across bitrate renditions (for ABR). But depending on where the WSE happens to join the stream, the first video packet received is rarely a keyframe, so the first chunk typically does not start on a keyframe.
That log code was added mainly to alert in the case where WSE stopped receiving keyframes and we had to force the ending of a chunk. So seeing many of these in the logs for the same stream indicates a significant issue, but just one at the beginning is normal.
If you are experiencing issues with audio only and no video, the only support we can provide is through a support ticket. We cannot solve this through the forums.
So is there any way to fix this at WSE side?I faced it and another warning:
WARNservercomment2019-05-3014:15:54-----97383.359--------CupertinoPacketHandler.handleHolder [liver/definst/live.tv.mystream1.stream] Ending the current a+v chunk although the chunk does not start with a video keyframe WARNservercomment2019-05-3014:16:59-----97448.472--------MPEGDashWriterHandler.endChunk[liver/definst/live.tv.mystream2.stream]: Stream start time calculation is off by 6130ms from original value. Changing stream start date from “Thu May 30 13:56:43 UTC 2019” to “Thu May 30 13:56:49 UTC 2019” WARNservercomment2019-05-3014:17:03-----97452.533--------MPEGDashWriterHandler.endChunk[liver/definst/live.tv.mystream3.stream]: Stream start time calculation is off by 5939ms from original value. Changing stream start date from “Thu May 30 13:56:49 UTC 2019” to “Thu May 30 13:56:43 UTC 2019” WARNservercomment2019-05-3014:18:37-----97546.402--------CupertinoPacketHandler.handleHolder [liver/definst/live.tv.mystream4.stream] Ending the current a+v chunk although the chunk does not start with a video keyframe WARNservercomment2019-05-3014:22:53-----97801.936--------CupertinoPacketHandler.handleHolder [liver/definst/live.tv.mystream5.stream] Ending the current a+v chunk although the chunk does not start with a video keyframe WARNservercomment2019-05-3014:22:55-----97804.118--------CupertinoPacketHandler.handleHolder [liver/definst/live.tv.mystream6.stream] Ending the current a+v chunk although the chunk does not start with a video keyframe
Let me see if we have come up with a solution to remove this error. Post again shortly.
Hi @Vinh Nguyen, I checked with our engineers and there is no way to stop this message from showing at this time. It will always notify you when there is no keyframe and log that warning. It can be ignored, but sorry for the inconvenience that it causes you from showing up.
Thank @Rose Power-Wowza Community Manager
Actually, I don’t want to hide these warning, just want to know how can I get rid off at transcode side. Anw, thank you for your quickly answer.
CupertinoPacketHandler.handleHolder [live/definst/sample-audiodestin] Ending the current a+v chunk although the chunk does not start with a video keyframe
How to fix this?
To review what has already been posted here @Crys.fmA, this is not an error or an issue, just a standard notification. HLS chunks that contain video are normally supposed to always start on keyframes to allow seamless switching across bitrate renditions (for ABR).
But depending on where the WSE happens to join the stream, the first video packet received is rarely a keyframe, so the first chunk typically does not start on a keyframe. You’ll get this notification and we have no way to block it at this time.
Let me look into that for you @Crys.fmA
It still remains the same notification that it is not starting with a keyframe. It’s not an error, but annoying I am sure to have it pop up. We don’t have a way to block it as of right now, but I let the engineers know of it.
My requirement is to add audio files to video only rtsp stream inputs. Tried both avmix and addaudiotrack module. Sometimes we get to see only audio in the output stream. Video information in playlist file is missing. Only see this error in logs. Trying different approaches but still when we mix a audio either from wowza modules or from external restreamers, Wowza doesn’t output video steam sometimes.
We are also facing same issue, we are also using addaudio module and AVmix module to insert audio to video stream, we are also getting same error logs and stream is also get buffering or freeze, it is working fine post restart of application.
I’m not sure how I can be any clearer on it- I have tried many times to explain it is a standard message making you aware when your video doesn’t start on a keyframe. It is not am error or warning. Last I checked with tech support, they said it’s not something that can be disabled, but perhaps you can submit a support ticket to see if they can run some tests which I cannot do here in the forums.
As I stated before, I have no doubt it’s annoying for you, so I would strongly suggest a support ticket to have our engineers test if it is related to the stream freezing. Sorry I can’t be of more help on this! But if you submit the ticket and request a solution, that will trigger an action request from our engineers.
Yes it is a warning only video doesn’t start on a keyframe. When this warning is seen, the playback hls url won’t have video stream information in playlist/chunklist file. So player’s play only audio stream. We fixed the issue by using ModuleIPCameraDynamicallySetAVSync and if the RTSP stream has SMP extension set these properties,
rtspFilterUnknownTracks: True
rtspStreamAudioTrack: False