Zap time
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]- Access network latency (processing/propagation delays):
- STB – IGMP Leave channel X, Join Y
- DSLAM – Stop X, Start Y
- DSL FEC/Interleave
- IGMP features used (version, fast leave, snooping, etc.)
- Availability of the channel (channel replication point)
- Core/aggregation network latency:
- Multicast routing mechanisms used
- 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]- Analyze data to locate MPEG program-specific information
- Obtain conditional access keys (ECMs) to decrypt channel: wait for ECMs – part of PMT – 100ms to 500ms
- Obtain MPEG key frame
- I-frame (MPEG 2) or IDR frame (H.264)
- One Index frame per group of pictures (GOP) – 12 to 30 (IBP) frames
- Typical frequency of I-frame – 500ms.
- 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]- ^ IPTV over DSL systems. "IPTV testing over DSL Archived January 26, 2007, at the Wayback Machine"
- ^ IPTV challenges and metrics. "IPTV Challenges Archived July 10, 2011, at the Wayback Machine"
- ^ IPTV