Apologies for the wall of text but some users have expressed concerns with the latest Tablo firmware load, specifically regarding buffering, macro-blocking and de-interlacing. Because of this, I’ve consulted with our engineering team to share some additional details on how Tablo works so that everyone can better understand Tablo’s behaviour on a typical home network.
About Buffering
Tablo uses a protocol called HTTP Live Streaming (HLS) to stream video from Tablo to clients (Roku, iPad, Android, PC…). HLS was created by Apple and uses HTTP to retrieve video files over the external Internet or your home network.
HLS works by dividing the video file (either recordings or live TV) into short segments that are delivered by a web server (in this case Tablo). The client (the video player in your phone, iPad etc.) controls this process. To playback a video from your Tablo, the video player on your device first requests a playlist file that describes the video and provides links to the individual segments that actually contain the video. A one-hour recording, for example, may have hundreds of individual video segments.
Once the video player reads the playlist, it starts making requests to retrieve the video segment files with the video and audio. An HLS segment file can be anywhere from 2 seconds to many minutes in length. Most players need to retrieve several segments before they begin displaying and playing back the video. This is so that they can build up a small buffer used to recover from issues with the Internet or LAN connection. For example, Apple players typically request at least 3 segments before you see anything on your screen.
In previous releases (prior to 2.1.18), we used fixed segment sizes. For live TV we used 4 second segments. Therefore, when you initiated playback of live TV in the video player, you would not see any video until the player had received 3 segments (4+4+4) or 12 seconds of video. In reality it takes longer than this since the Tablo needs to receive the first segment before it can build it and transmit it (4 seconds) and it takes additional time to tune the channel, set up the transcode path and to record it to disk. In 2.1.16 the total time to wait was around 18s. Many users felt this was too long so we worked to identify ways we could reduce this time.
One way is to reduce the segment size, but this has the downside of creating a lot more segments, which increases the size of the playlist. This can cause a problem for live TV since the player must reads the playlist at frequent intervals during playback.
Another solution is to stagger the segment sizes. This is the approach we used in 2.1.18. Instead of a fixed segment size, we start with 2-second segments and ramp up to 10 seconds. The first 3 segments are each 2 seconds in length, which cuts the start-up time to 6 seconds from 12 seconds. For most people, this is a good compromise and eliminates 8 or so seconds of wait.
However, a consequence of this is that player has buffered only 6 seconds instead of 12 seconds of video. If your home network experiences issues, this may cause you to see stuttering (brief pauses in video playback) where there was no stuttering previously. Users experiencing this likely already had networks with lower bandwidth capabilities. In most networks, the loss of a few seconds of buffering in the client video player should have no effect.
If you are experiencing this, the best solution is to improve your home network (either by tuning your WiFi or adding a more robust router) so that the segments are not delayed. You can also manually pause the video within the player for a few seconds, which will also build up a buffer.
We will also consider adding a setting to the next Tablo firmware release which will enable a switch back to fixed segment sizes. It is important to note that the change only affects the first minute or so of playback. By the end of a minute, the segments sizes are the same as the 2.1.16 release. If you see persistent stuttering problems later in the video, there may be other issues at play.
This is the only change to video processing in this release.
About Deinterlacing
The ATSC standard supports several different video formats, but the most common ones are 1080i, 720p and 480i. 1080i is the most challenging. The ‘I’ in 1080i stands for interlaced. Most other formats use a progressive format to encode the video which means that each frame (or picture) of the video is transmitted as a single frame. To playback the video, the player just displays a frame and then displays the next frame, and so on and so on.
Interlaced video is a bit different. For interlaced video, a single frame is actually divided into two parts, one with the odd number horizontal lines and the other with the even number horizontal lines. So for the player to display a single frame, it plays the even lines and then plays the odd lines. Back in the days when we used CRT technology in televisions, the persistence of the phosphor would keep both the even and odd lines on the screen at the same time and the viewer’s eyes would perceive a complete picture. Now with digital technology, this approach no longer works. The display now has to store the even lines and then add in the odd lines to create a complete frame that it displays to the user. This is called de-interlacing and it converts interlaced content to progressive content. All digital displays need to do this and therefore most modern streaming formats used on the internet are all progressive formats (like 720p). In fact, most modern video players will not play interlaced video. That is why Tablo always converts 1080 interlaced to 1080 progressive before streaming it to your device. If it did not, the video would likely not play on your device of choice – for example iOS only supports progressive - or in the best case, it would work on one device and none of the others.
However, de-interlacing is not as simple as pasting the two frames together. If there is fast movement in the video content between when the odd lines were captured and the when the even lines were captured, you will see artifacts in the new progressive frame. To get around this, devices use various strategies to de-interlace the video so that the motion does not cause a problem. De-interlacing is very computationally intensive. Tablo needs to de-interlace multiple streams of video (and transcode it to H.264) in real time, and at an affordable price. While we use the best chips that are available to us, with current technology it remains possible to see some artifacts under certain circumstances.
We have worked hard to improve de-interlacing performance since launch and made some significant improvements in 2.1.16. There have been no changes to de-interlacing in 2.1.18. With Tablo creating multiple streams at 1080i transcoded to 1080p the hardware is reaching the limits of its performance. This is less of an issue at 720p output and therefore de-interlacing does perform better for 720p output streams. We continue to work with our chip vendor to improve de-interlacing performance but we may have to wait for the next generation of silicon to make substantial improvements.
About Macroblocking
All video formats use ‘lossy’ compression to encode video and cannot completely replicate the original. To record Over-the-Air video, Tablo converts MPEG 2 video to H.264. H.264 is a modern, more efficient codec which can use less than half the bit rate to store the same video information. We also chose H.264 because MPEG 2 is not supported by most modern devices (Roku, smartphones, tablets...)
To make a recording or to stream live TV, Tablo decodes the MPEG 2 video and then encodes it back into H.264. To do this in real time we use a hardware-accelerated H.264 encoder. Companies like Netflix encode their video using a software-based two-pass encoder since there is no need to do it in real time. The first pass previews the video so that the encoder understands how best to encode it and can optimise how much bandwidth it uses. Unfortunately, the Tablo does not have this luxury and must encode all the video in real time as it is received.
Therefore, for sequences with very fast scene changes, it is possible for the encoder to be momentarily
overwhelmed. This can cause very brief periods of macro-blocking whereby the pixel structure appears more coarse (or blocky) than usual. This usually only persists for a fraction of a second and is only really
noticeable if you pause the video at that point. Unfortunately, it is a consequence of the need to encode in real time at an affordable cost. The chip set we use is one of the very best and it is very unusual to see macro blocking in most video. If it seems to persist, it could be in the source MPEG 2 video or could be due to other issues such as high bit error rates in the incoming video due to reception issues.
What does this mean?
Every day we are working very hard to make Tablo more awesome. We hear your concerns and we do our very best to deliver an amazing experience for Over-the-Air TV. We will keep pushing the technological constraints of the hardware and software we use and striving to make our product the best on the market today. All we can ask is that you give us the time to continue to make improvements and understanding when we are faced with the limitations of today’s technology.
If you have any questions about this content, please feel free to reply to this post and we’ll do our best to answer.
