This is a great update. Good stuff. Works great.
Good job! Keep up the good work!!
When is the feature for saving recordings to PC coming?
I would like to add that my buffering is is only on live TV. Recordings play fine with no buffering. Prior to the update, beta included, I had no issues with buffering at all. I do not think this is hard drive related at all, but more so with the reduced buffer on live TV to speed up tuning.
@hdmkv - It’s on the to-do list but I don’t have an ETA to share.
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.
Great write up. Thanks for taking the time.
I am becoming concerned the the hardware design of the Tablo is underpowered for the task of encoding in real time if the silicon or algorithm in Tablo has difficulty processing/de-interlace 1080i video content -> 1080p without artifacts during motion, particularly during sports. This is not an issue with nearly any other DVR including Tivo/cable/satellite which do not have 12-15 seconds of lag time for streaming to clients. Even Windows MCE which re-encoded everything didn’t have issues with such a long lag time or issues with 1080i video content. Perhaps Tablo version 2 can have better hardware.
@BraveUpNorth Thanks for the feedback!
@7up The difference here is that other DVR’s (Tivo/Cable/Satellite) don’t transcode the Mpeg2 to H.264 – so they can’t run into the same issue. They record in native and play back in native Mpeg2.
We use H.264 to stream to mobile and internet devices like Roku, Apple TV & Chromecast that do not support Mpeg2. The same can be said for Windows MCE devices; they record and play back in Mpeg 2, but can't mobile or 'internet' devices. Basically, if we want to send it to your other devices, and not your TV, it has to be transcoded.
As I posted in another thread … I think above all else getting the right antenna size (yes there is such thing as too big) (and you can over amplify as well) and the location/orientation of the properly sized antenna is perhaps the most vital thing in getting the best performance out of your tablo … more so (if like me) you live a good distance away from the broadcast towers… even in “good” reception areas if you do not have your antenna mounted correctly or located in a place thats subject to external interference (i.e. reflection of moving objects/people/etc, or you are too close to another stations transmitter) … you can significantly degrade your reception and suffer problems… DTV unlike analog is “either it works or it doesnt” … there is no “snowy picture” … you either get a great picture or it just out dies or you suffer blocking and other problems.
@BraveUpNorth Thanks for the feedback!@7up The difference here is that other DVR’s (Tivo/Cable/Satellite) don’t transcode the Mpeg2 to H.264 – so they can’t run into the same issue. They record in native and play back in native Mpeg2.We use H.264 to stream to mobile and internet devices like Roku, Apple TV & Chromecast that do not support Mpeg2. The same can be said for Windows MCE devices; they record and play back in Mpeg 2, but can't mobile or 'internet' devices. Basically, if we want to send it to your other devices, and not your TV, it has to be transcoded.
I’m not trying to debate with you but some of your statements are incorrect. Satellite doesn’t record or playback in mpeg2 as the feeds have already been transcoded to h.264 or some variant before uplinking. You somewhat acknowledged this with your comments about 2-pass encoding above. I haven’t looked at local cable TV recordings in a long time so I don’t know how they are currently encoding their feeds. Your statement that transcoding is necessary for wireless clients, ie tablets, phones, Roku, and even FireTV, is correct which emphasizes the need for sufficient video processing.
As we agree its necessary for Tablo has to transcode to h.264, I would respectfully suggest the processor chosen for the task is insufficient which is the cause for the long lag times, an image with artifacts during motion and why you still recommend 720p.
Its just a thought but why not release Tablo as software for the PC/Mac which have significantly greater processing power for transcoding or work with SiliconDust using their existing h.264 tuner. I’m not suggesting discontinuing developing and selling hardware but you would expand your potential customer pool.
@TabloSupport. First off thanks for the phenomenal write up, as that provides a lot of info related to the inner workings of the Tablo. I have been with your company since the start ( pre-sale ) of the 4 tuner. We couldn’t be happier with the product and my wife factor has said she doesn’t even miss cable! To achieve the best setup for our whole home DVR I tested wifi at first with Tablo and Rokus and did not like the latency that brought to our viewing experience. So I hard wired everything to provide as near of a experience we have been used to. Tablo is hard wired via Powerline adapter sustaining 250Mbps or more. Roku 3 connects to TV is hard wired directly to gigabit Cisco router. Living room Roku 3 is hard wired with Powerline adapter also sustaining 250Mbps or more. We have never had an issue with buffering with this setup on Live TV and recorded episodes. After the beta 2.1.1.17 and also public release 2.1.1.18 we have experienced buffering on only Live TV. This can happen right away, or after watching LiveTV after three hours straight. I should have reported it right away after I noticed it in the Beta release, but got busy and I apologize as that is what us beta testers are for. I thought if it was my network, I would experience buffering while streaming from my plex server or from the Internet or even from the recorded Tablo episodes. Hopefully the next release comes out soon so I can test reverting back to the old way how Live TV is handled and report back if buffering is gone. Thanks again for an awesome product!!! I hope Tablo does not take our user experience reports via the forum negatively as we all want Tablo to stay for a long time, just get better over time as with all technology!
Ok after playing around with just live tv and the roku+tablo I can confirm I too got the buffering a few times … even well after a program was in progress… that said… following supports suggestion, pausing the playback for a couple mins totally removed the buffering completely (I used 2 mins as I stepped away to get a cup of coffee) … I suspect pausing it only a minute would probably be sufficent to remove the buffering issue.
@TabloSupport Don’t want to open another can of uncontrollable variables, but is there a preferred router(s)? Thanks, in the market for a new one and figure I’ll get what works best for the Tablo > Chromecast.
I am becoming concerned the the hardware design of the Tablo is underpowered for the task of encoding in real time if the silicon or algorithm in Tablo has difficulty processing/de-interlace 1080i video content -> 1080p without artifacts during motion, particularly during sports. This is not an issue with nearly any other DVR including Tivo/cable/satellite which do not have 12-15 seconds of lag time for streaming to clients. Even Windows MCE which re-encoded everything didn’t have issues with such a long lag time or issues with 1080i video content. Perhaps Tablo version 2 can have better hardware.
The hardware is more then capable even though the SOC their using is four years old. The quad unit uses the Vixs 5190 SOC which has hardware based transcoding. I would assume the functions for transcoding have configurable options. This may be something that needs to tweaked. Artifacts during transcoding are normally caused by frame rate reduction and/or compression.
@TabloTV and @TabloSupport - Good update! Important resume feature (hasn't happened to me yet, but glad you thought of it, and a bit speedier, for sure!
iOS downloadable web app has worked seamlessly. I am now all systems go!
I am becoming concerned the the hardware design of the Tablo is underpowered for the task of encoding in real time if the silicon or algorithm in Tablo has difficulty processing/de-interlace 1080i video content -> 1080p without artifacts during motion, particularly during sports. This is not an issue with nearly any other DVR including Tivo/cable/satellite which do not have 12-15 seconds of lag time for streaming to clients. Even Windows MCE which re-encoded everything didn't have issues with such a long lag time or issues with 1080i video content. Perhaps Tablo version 2 can have better hardware.The hardware is more then capable even though the SOC their using is four years old. The quad unit uses the Vixs 5190 SOC which has hardware based transcoding. I would assume the functions for transcoding have configurable options. This may be something that needs to tweaked. Artifacts during transcoding are normally caused by frame rate reduction and/or compression.
I’m familiar with Vixs as a company but not specifically their product line. Most silicon designs undergo significant improvements over the 4 years since this chip was introduced. If the hardware is more than capable may I ask why,
- there is a ~15 second lag time, the overwhelming majority of which is transcoding?
- Tablo has difficulty processing 1080i video content with motion -> 1080p without artifacts (macroblocking)?
- How much control over the level of compression is possible with the hardware based encoding of the 5190?
It would nice if Tablo allowed some user configurable transcoding profiles similar to what is/was possible with SD HDTC-2US. I would be curious to hear how the Tablo’s trancoding compares to HDTC-US “heavy profile” in terms of lag time and picture quality.
I’m familiar with Vixs as a company but not specifically their product line. Most silicon designs undergo significant improvements over the 4 years since this chip was introduced. If the hardware is more than capable may I ask why,
- there is a ~15 second lag time, the overwhelming majority of which is transcoding?- Tablo has difficulty processing 1080i video content with motion -> 1080p without artifacts (macroblocking). How much control over the level of compression is possible with the hardware based encoding of the 5190?
As what was previously stated its not just the transcoding that is
leading to the delay. There are many other operations that occur
before, during and after transcoding. You also have to remember that
the de-interlacing and transcoding is happening real-time. Its far easier to convert 1080i to 720p algorithmically. I personally would like to the option of having 1080i streams converted 720p.
All hardware based algorithms provide some level of parameter tweaking. As to which parameters are available on the Vixs I have no clue. But I do know Vixs chips are used in everything from Samsung TV’s to Tivo. They dominate the PVR market and have quite a few patents around Marcoblocking.