Short freeze when switching streams using Scheduled Channel

[nums]

Hi,

I’m currently using the Scheduled Channel feature in OvenMediaEngine to switch between different streams automatically.

However, I’m experiencing a short freeze (a few seconds) every time the stream switches from one source to another. During this transition, playback stops briefly before resuming normally.

Details:

• The freeze occurs consistently at each scheduled switch
• Duration: approximately a few seconds, but the audio is already playing well
• Playback resumes correctly after the freeze
• Resources on the machine are ok (20/30% of cpu)

You can watch here an example:
https://streamable.com/pu8dxx

Schedule xml file :

<?xml version="1.0" encoding="UTF-8"?>
<Schedule>
	<Stream>
		<Name>streamsch</Name>
		<BypassTranscoder>false</BypassTranscoder>
		<VideoTrack>true</VideoTrack>
		<AudioTrack>true</AudioTrack>		
	</Stream>

    <FallbackProgram> 
        <Item url="stream://default/app/waiting" duration="-1" />
    </FallbackProgram>

    <Program name="origin" scheduled="2000-01-01T20:57:00.000+09" repeat="true">
        <Item url="stream://default/app/live" duration="-1" />
    </Program>
</Schedule>

Server.xml OutputProfile part:

<OutputProfile>
		<Name>bypass_stream</Name>
		<OutputStreamName>${OriginStreamName}</OutputStreamName>
		<Playlist>
			<Name>default</Name>
			<FileName>master</FileName>
			<Options>
				<WebRtcAutoAbr>true</WebRtcAutoAbr>
				<HLSChunklistPathDepth>0</HLSChunklistPathDepth>
				<EnableTsPackaging>true</EnableTsPackaging>
			</Options>
			<RenditionTemplate>
				<Name>${Height}p</Name>
				<VideoTemplate>
					<EncodingType>all</EncodingType>
					
				</VideoTemplate>
				<AudioTemplate> 
					<EncodingType>all</EncodingType>
					
				</AudioTemplate>
			</RenditionTemplate>
		</Playlist>
		<Encodes>
			<Audio>
				<Name>aac_audio</Name>
				<Codec>aac</Codec>
				<Bitrate>128000</Bitrate>
				<Samplerate>48000</Samplerate>
				<Channel>2</Channel>
				<BypassIfMatch><Codec>eq</Codec></BypassIfMatch>
			</Audio>
			<Audio>
				<Name>opus_audio</Name>
				<Codec>opus</Codec>
				<Bitrate>128000</Bitrate>
				<Samplerate>48000</Samplerate>
				<Channel>2</Channel>
				<BypassIfMatch><Codec>eq</Codec></BypassIfMatch>
			</Audio>
			<Video>
				<Name>video_1080p</Name>
				<Codec>h264</Codec>
				<Bitrate>3000000</Bitrate>
				<KeyFrameInterval>30</KeyFrameInterval>
				<BFrames>0</BFrames>
				<Framerate>30</Framerate>
				<Width>1920</Width>
				<Height>1080</Height>				
			</Video>
		</Encodes>
	</OutputProfile>
</OutputProfiles>

Part of log when switch appear :

[2026-04-21 09:27:23.253] E [dec_H264_t0:238] FFmpeg | third_parties.cpp:113  | [AVCodecContext: 0x7feef506bc00] non-existing PPS 0 referenced
[2026-04-21 09:27:23.253] E [dec_H264_t0:238] FFmpeg | third_parties.cpp:113  | [AVCodecContext: 0x7feef506bc00] decode_slice_header error
[2026-04-21 09:27:23.253] E [dec_H264_t0:238] FFmpeg | third_parties.cpp:113  | [AVCodecContext: 0x7feef506bc00] no frame!
[2026-04-21 09:27:26.113] I [AW-LLHLS0:56] LLHLS Publisher | llhls_stream.cpp:1768 | LLHlsStream(#default#app/live) - Ready to play : Part Hold Back = 1.500000
[2026-04-21 09:27:33.111] I [AW-HLSv30:58] HLS Publisher | hls_stream.cpp:543  | HLS Stream(#default#app/live) - All playlists are ready to play

I know that the error on FFmpeg | third_parties.cpp:113 has no impact

I would like to know:

• Is this expected behavior when using Scheduled Channels?
• Are there any recommended configurations or best practices to avoid or reduce this interruption?
• Is there a way to achieve seamless switching between streams? with api?

Thanks in advance for your help!

[getroot]

There are several scenarios.

1. Switching from live stream A to live stream B

1.1. If both live stream A and B already exist internally, switching by changing the Program happens quickly.

1.2. If live stream B is newly incoming and the switch happens automatically from Fallback to Program, some delay is unavoidable until live stream B is initialized. This becomes more noticeable when the keyframe interval is longer.

2. Switching from ANY to a file
   This is expected to switch immediately in all cases.

So, if you want to make this transition very smooth, you should first confirm that the live stream has been initialized in the system, and then create the Program in the Schedule using the API.

[nums]

After running additional tests, I’d like to share more details:

I tested switching between a file source and a live stream using the API (the stream is already fully ready on the server side before switching). I performed several switches.

When switching to the video file, the transition is seamless.
However, when switching to the live stream, I consistently get a freeze of about 1 to 3 seconds.

For reference:

• Keyframe interval: 30
• Framerate: 30 fps

Do you think this behavior could be related to keyframe alignment?

Would it make sense to implement switching at the moment a keyframe is encountered in the incoming stream to achieve a smoother transition?

[nums]

I’d also like to add another observation:

It seems that these freezes may introduce a synchronization issue on the player side. It’s a bit unusual - when I initially connect to the stream, audio and video are properly synchronized.

However, if I stay on the same player session and perform multiple switches, I start noticing an audio/video desynchronization.

On the other hand, when I watch the stream directly (without going through the Scheduled Channel), I do not observe any desynchronization, even after several hours of playback.

[getroot]

The audio might be bypassing instead of encoding due to BypassIfMatch. Would you like to try testing without BypassIfMatch?

[nums]

I made this update and it seems that there is no more synchronization issue. The freeze still there.

[getroot]

When switching to live, if the channel joins the live stream in the middle, the A/V timestamps do not start at 0 and 0. Instead, they may start with a gap such as 100 and 120. To resynchronize them, the transcoder inserts padding on the video side, and that may be what causes the stream to appear frozen.

In contrast, files usually start at 0 and 0, so the transition is smoother. A slight freeze of less than 1 second is expected, but 3 seconds is too long.

To minimize this, the live input A/V must be very tightly interleaved. For example, if a live source sends 1000 ms of video first and then 1000 ms of audio, that gap will appear accordingly.

[nums]

Thanks, I hadn't understood one thing: the scheduler uses the original stream, not the encoded stream. I just applied a framerate of 30 to my original stream and I'm getting about a one-second freeze.
I will try change some advanced settings on my encoder to see if I can minimize this.

[nums]

Ok, I see that there is a first work about "waiting keyframe strategies" process here :

OvenMediaEngine/src/projects/providers/scheduled/scheduled_stream.cpp

Line 1202 in be6b79e

// stream_tap->SetNeedPastData(true);

OvenMediaEngine/src/projects/providers/scheduled/scheduled_stream.cpp

Line 1009 in be6b79e

// Transcoder will make bogus frame if it can't be decoded