Lag problem for STBs when changing channels?
The factors that influence zapping are: network latency (CPE, switches, routers), buffers (network dejittering, additional buffers in STB), the speed of the application interpreting the type and the elements in stream and video audio decoder. If buffers we don’t consider comparative with the rest, playing from STB is quite difficult first of all due to the way compression is built (MPEG2 or H264)
At MPEG2, the structure of GOP (Group of pictures) has about two I-frames per second (an I-frame is a full frame from the 25 per second as a kind of JPEG picture) completed by P and B (information such as the difference between successive frames, some even between previous and subsequent frames). The STB decoder can not play unless it receives a reference (I-frame) and then begin playback by reconstructing the image using P and B.
So how fast can we change the TV channels with IPTV tech?
With STB we have to wait approx half a second. At H264, compression is even more effective, but it is mainly based on the shrinking of Type I frames which occupies most of the information (P and B are differences, occupy much less). Default GOP H264 allows about one I-frame per second. It’s clear to MPEG2 that the zapping is better than H264. And at H264 It can alter the GOP to speed up zapping at the expense of bitrate. There are still delays in the application interprets the codec, synchronizes audio with video, discovers the elements of the stream (audio, video
teletext, subtitles, etc.) which, depending on how well it is written, “eats” up to 2 seconds. In real life an IPTV on
MPEG2 flashes at 1-1.5 seconds and one on H264 switches to 2.5-3 sec. Until now I explained the part of the decoder.
In the networking area, to call a stream to STB when we change the channel, a request is made to the network. If in
the first networking equipment consumes some of the channel, it is automatically sent to us. If no, it is required upstream to the next equipment (the explanation is valid for IPTV multicast operators).
The time until the stream reaches us affects zapping. In a poor node in subscribers, channel change is can make it hard, as subscribers multiply the likelihood that that channel is being watched by another subscriber increases
and our experience with zapping should improve. Things are not exactly that, because to filter the streams (channels) the networking equipment starts sweating (IGMP snooping) and transports the packages harder and harder.
When network equipment is either at the limit, or poorly configured, zapping can go to 7-8 seconds. The CPE (router) of the subscriber’s home (which has to be inexpensive) contributes decisively to delays.
In the meantime, the client becomes accustomed even if the zapping is slow. Worse is when coming from the analog cable where the channels is changing relatively quickly.