Zap time explained

The zap time is the total duration of time from which the viewer changes the channel using a remote control to the point that the picture of the new channel is displayed. This includes the corresponding audio. These delays exist in all television systems, but they are more pronounced in digital television and systems that use the internet such as IPTV. Human interaction with the system is completely ignored in these measurements, so zap time is not the same as channel surfing.

Zap time can be very disturbing for some viewers and for this reason it is considered an issue that must be addressed in IPTV systems.^[1]

Factors

The delays when changing the channel can be caused by several different factors. These factors can be classified according to the systems that cause them. Consequently, there are network factors, MPEG acquisition factors, and set top box buffering/decode factors.^{[2] [3]}

Network Factors

• Access network latency (processing/propagation delays):

1. STB – IGMP Leave channel X, Join Y
2. DSLAM – Stop X, Start Y
3. DSL FEC/Interleave
4. IGMP features used (version, fast leave, snooping, etc.)
5. Availability of the channel (channel replication point)

• Core/aggregation network latency:

1. Multicast routing mechanisms used
2. Availability of the channel (channel replication point)

Network factors tend to make up only a small portion of the overall delay, between 50 and 200ms of the overall zap time. Network quality of service (QoS) can reduce these time to minimize jitter, latency, and packet drop.

MPEG Acquisition Factors

• Analyze data to locate MPEG program-specific information

1. Wait for and parse PAT (Program Association Table)
2. Wait for and parse PMT (Program Map Table)

• Obtain conditional access keys (ECMs) to decrypt channel: wait for ECMs – part of PMT – 100ms to 500ms
• Obtain MPEG key frame

1. I-frame (MPEG 2) or IDR frame (H.264)
2. One Index frame per group of pictures (GOP) – 12 to 30 (IBP) frames
3. Typical frequency of I-frame – 500ms.
4. Long GOP structure (2–4 seconds) saves bandwidth, but can cause significant channel change latency

Set Top Box Buffering/Decode Factors

• MPEG Buffer: Encoder buffer fullness model (typical latency – 750ms to 2s). Wait until the buffer is full.
• Decode/Display delay (typically about 50 ms)

Zap Time Examples

The various factors that affect zap time do not do so in the same way. The table below is an example of zap time in IPTV DSL:

	Channel Change Latency Factor	Device/Location	Typical Latency	Cumulative Latency
1	Send IGMP Leave for channel X	STB	< 10 ms
2	Send IGMP Join for channel Y	STB	< 10 ms
3	DSLAM receives Leave for channel X	DSLAM/Network	< 10 ms
4	DSLAM receives Join for channel Y	DSLAM/Network	< 10 ms	~ 20 - 40 ms
5	DSLAM stops channel X, and sends Channel Y	DSLAM/Network	~ 30 – 50 ms	~ 50 – 90 ms
6	DSL Latency (FEC/Interleave)	DSLAM/Network	~ 10 ms	~ 60 - 100 ms
7	Core/Agg Network Latency	Router/Network	~ 20 – 60ms	~ 80 – 160ms
8	De-jitter buffer	STB	~ 300 ms	~ 380 - 460 ms
9	Wait for PAT/PMT	STB MPEG buffer	~ 125 ms	~ 500 - 580 ms
10	Wait for ECM/CA	STB MPEG buffer	~ 125 ms	~ 620 - 700 ms
11	Wait for I-frame	STB MPEG buffer	~ 250 ms to 2s	~ 870 ms – 2.7s
12	MPEG buffer	STB MPEG buffer	~ 1s to 2s	~ 1.8s – 4.7s
13	Decode	STB	~ 50ms	~ 1.9s – 4.8s

Zap time delays are greater in IPTV television than in other technologies. For example:

• Analog (Cable) ~ 0.01 - 1s
• Analog (off-air) ~ 0.01 – 3s
• MPEG2 over QAM ~ 1.2 – 3s
• MPEG2 over QPSK ~ 2 – 4s
• MPEG2 over IP Multicast ~ 1.5 – 3.5s
• H.264 over IP Multicast ~ 1.7 – 4s

External links

• ITU IPTV Focus Group
• ITU-T. Zap time.

Notes and References

1. IPTV over DSL systems. "IPTV testing over DSL "
2. IPTV challenges and metrics. "IPTV Challenges "
3. https://subscriptioniptv.com IPTV