# Zap time

> Mediated Wiki article. Canonical URL: https://mediated.wiki/source/Zap_time
> Markdown URL: https://mediated.wiki/source/Zap_time.md
> Source: https://en.wikipedia.org/wiki/Zap_time
> Source revision: 965052706
> License: Creative Commons Attribution-ShareAlike 4.0 International (https://creativecommons.org/licenses/by-sa/4.0/)

The '''zap time''' is the total duration of time from which the viewer changes the channel using a [remote control](/source/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](/source/television) systems, but they are more pronounced in [digital television](/source/digital_television) and systems that use the [internet](/source/internet) such as [IPTV](/source/IPTV). Human interaction with the system is completely ignored in these measurements, so zap time is not the same as [channel surfing](/source/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.<ref name="iptv_overdsl">IPTV over DSL systems. "[http://documents.exfo.com/appnotes/anote148-ang.pdf '''''IPTV testing over DSL'''''] {{webarchive |url=https://web.archive.org/web/20070126082442/http://documents.exfo.com/appnotes/anote148-ang.pdf |date=January 26, 2007 }}"</ref>

==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](/source/television_network) factors, [MPEG](/source/MPEG) acquisition factors, and [set top box](/source/set_top_box) buffering/decode factors.<ref name="metrics">IPTV challenges and metrics. "[http://documents.exfo.com/appnotes/anote174-ang.pdf '''''IPTV Challenges'''''] {{webarchive |url=https://web.archive.org/web/20110710211624/http://documents.exfo.com/appnotes/anote174-ang.pdf |date=July 10, 2011 }}"</ref>
<ref>[https://subscriptioniptv.com IPTV]</ref>

===Network Factors===
*[Access network](/source/Access_network) latency (processing/propagation delays):
#[STB](/source/Set_Top_Box) – [IGMP](/source/IGMP) Leave channel X, Join Y
#[DSLAM](/source/DSLAM) – Stop X, Start Y
#DSL FEC/Interleave
#[IGMP](/source/IGMP) features used (version, fast leave, snooping, etc.)
#Availability of the channel (channel replication point)

*[Core/aggregation network](/source/Core_network) latency:
#Multicast [routing](/source/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](/source/quality_of_service) (QoS) can reduce these time to minimize [jitter](/source/jitter), latency, and packet drop.

===MPEG Acquisition Factors===
*Analyze data to locate MPEG [program-specific information](/source/program-specific_information)
#Wait for and parse [PAT](/source/MPEG_transport_stream) (Program Association Table)
#Wait for and parse [PMT](/source/MPEG_transport_stream) (Program Map Table)

*Obtain [conditional access](/source/conditional_access) keys (ECMs) to decrypt channel: wait for ECMs – part of PMT – 100ms to 500ms
*Obtain [MPEG](/source/MPEG) key frame
#[I-frame](/source/I-frame) (MPEG 2) or IDR frame ([H.264](/source/H.264))
#One Index frame per [group of pictures](/source/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===
*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:
{| class="wikitable" border="1"
|-
! 
! 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](/source/Forward_error_correction)/[Interleave](/source/Forward_error_correction))
| 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](/source/Cable_television)) ~ 0.01 - 1s
*Analog ([off-air](/source/off-the-air)) ~ 0.01 – 3s
*MPEG2 over [QAM](/source/QAM) ~ 1.2 – 3s
*MPEG2 over [QPSK](/source/QPSK) ~ 2 – 4s
*MPEG2 over IP Multicast ~ 1.5 – 3.5s
*H.264 over IP Multicast ~ 1.7 – 4s

==References==
{{Reflist}}

==External links==
*[https://web.archive.org/web/20081126060537/http://www.itu.int/ITU-T/IPTV/ ITU IPTV Focus Group]
*[http://www.itu.int/md/T05-FG.IPTV-C-0545/en ITU-T. Zap time.]

Category:Digital television

[es:Zapeo](/source/es%3AZapeo)

---
Adapted from the Wikipedia article [Zap time](https://en.wikipedia.org/wiki/Zap_time) by Wikipedia contributors ([contributor history](https://en.wikipedia.org/wiki/Zap_time?action=history)). Available under [Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/). Changes may have been made.