Zap time
![]() | This Digital TV provides insufficient context for those unfamiliar with the subject. |
The zap time is the total duration from the time viewer presses the channel change button, to the point the picture of the new channel is displayed, along with corresponding audio. 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 the viewer since he has to wait too much time when decides to switch the channel. For this reason, zap time is an IPTV feature that we must keep in mind when we use an IPTV system.
Factors
The delays in the TV channel change can be caused by different factors. We can classify these factors according to the systems that cause them. Consequently we have network factors, MPEG acquisition factors and Set Top Box Buffering/Decode.
Network Factors
- 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)
Actually, these are only a small component of delay in the final time. Usually they take about 50 - 200 ms of the overall zap time. Network quality of service(QoS) can reduce these time ensuring minimal jitter, latency and packet drop.
MPEG Adquisition
- Analyze data to locate MPEG PSI Info
- Obtain conditional access keys (ECMs) to decrypt channel: wait for ECMs – part of PMT – 100ms to 500ms
- Obtain MPEG key frame
- I-frame (MPEG2) 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 causes significant channel change latency
Set Top Box Buffering/Decode
- MPEG Buffer: Encoder buffer fullness model (typical latency – 750ms to 2s). Wait until the buffer is full
- Decode/Display delay (typically about 50 ms)
Computing Zap Time
The factors that has been explained in the last section don't affect in the same way to the overall zap time. So in the table below there are an example of the 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 gets Leave for channel X | DSLAM/Network | < 10 ms | |
4 | DSLAM gets 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 |
Examples
In this section some typical values of zap time are shown. How you can see, in IPTV television these delays are greater than in other technologies:
- Analog (Cable) ~ 1s
- Analog (off-air) ~ 1 – 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