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 edit

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 edit

  1. STBIGMP 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)
  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 edit

  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 edit

  • 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 edit

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

References edit

  1. ^ IPTV over DSL systems. "IPTV testing over DSL Archived January 26, 2007, at the Wayback Machine"
  2. ^ IPTV challenges and metrics. "IPTV Challenges Archived July 10, 2011, at the Wayback Machine"
  3. ^ IPTV

External links edit