xxxx cccc xx cc
(Had to go hunt up a longish ethernet cable.) Done. Performance wired and wireless was almost the same – 16 Mbps with the wire, and up to 15.1 Mbps wireless. Either way, the Roku said it was receiving 1.5 Mbps.
And here’s the really weird part – I reset the Tablo to 1080p, power-cycled it, power-cycled the Roku, and ran both wired and wireless at 1080p. The Roku still said it was receiving 1.5 Mbps @16 to 13 Mbps (or as low as 10 Mbps wireless)… but no “loading please wait” messages either wired or wireless! What magic is this?! Two weeks ago Live TV and anything recorded at 1080p was simply unwatchable. NOTHING has changed in my setup other than resetting the Tablo to 720p. Possibly daytime TV is not as ‘rich’ as evening TV? We deleted the old recordings at 1080p after we watched them on the labptops, so I can’t test with those.
Thoughts?
xxxx cccc xx cc
I guess. I don’t quite trust it. Any clue why the Roku is receiving only 1.5 Mbps?
xxxx cccc xx cc
I set the Roku to select an automatic bitrate. The Tablo was set to 720p but is now set to 1080.
xxxx cccc xx cc
Roku is set for 1080p resolution. It was previously set to 720p. Are you saying that could have created a conflict if the Tablo was sending 1080 and Roku set to 720?
At either resolution setting, the Roku says that it is receiving at 1.5 Mbps bitrate. Earlier you had said that the 720p setting (presumably the Tablo setting) is encoded at about 5 Mpbs, so I am wondering why the Roku isn’t receiving at that bitrate, and why what the Roku reports it is receiving did not change when I reset the Tablo to 1080.
I’m happy that it seems to be working, but I would trust it more if I understood it. Thanks!
xxxx cccc xx cc
He/she is likely using a secret menu in the Roku, which for years now has not been accurate at reflecting the wireless throughput nor the stream bitrate.
The “Display type” setting on the Roku is separate from the Tablo recording quality setting. I would leave this as “1080p HDTV” regardless of the recording quality setting you use on Tablo.
The 1080p recording setting on the 2.2.2 firmware records 1080i 30 fps source content as 1080p 30 fps h.264 video, which the Roku 3 has no problem playing. The 1080p recording setting on the 2.2.2 firmware records 720p 60 fps source content as 720p 60 fps h.264 video, which SOME Roku 3’s have problems playing which results in the “loading… please wait” messages.
The solution for this until Tablo Support releases the 2.2.5 firmware is to drop down to the 720p recording setting. Or you can contact Tablo directly and have them release the beta to you for the 2.2.5 firmware. The new recording quality you will want is the ‘1080p 8 Mbps’ setting which does not record in 60 fps.
Yes, “she” 
is using the secret menu on the Roku, but I did not realize that it did not give accurate results. That’s disappointing.
I had dropped down to the 720p recording setting on the Tablo, but I was very unhappy with the video/picture quality at that setting. I am anxiously awaiting the release of 2.2.5, but I really don’t have time or expertise to be a beta tester. So the point of my original post was to see if I could get a better Tablo experience sooner by moving off of the Roku interface onto the FireTV (or maybe the new Apple TV) interface.
The “loading … please wait” message seems to be gone from the Roku 3 setup in the TV room. I’ll see how it does with a football game this weekend. The Roku stick on the bedroom setup is still not handling input well, and I still get the “loading … please wait” message there, but I rather expected that. Now that I think on it, getting a FireTV or AppleTV to replace the Roku stick may be a good way to compare Roku to something else. On the other hand, I’m not sure the hubster is going to like having to figure out a different menu structure on a new device. It warrants more thinking.
Thank you all for your input. It is very much appreciated!
I would expect a live 2.2.5 within the next week or two but that’s just pure speculation on my part.
xxxx cccc xx cc
Thanks, again!!
Re- @theuser86 Hold on for next FW upgrade, or move to FireTV interface?
““
The 1080p recording setting on the 2.2.2 firmware records 1080i 30 fps source content as 1080p 30 fps h.264 video, which the Roku 3 has no problem playing. The 1080p recording setting on the 2.2.2 firmware records 720p 60 fps source content as 720p 60 fps h.264 video, which SOME Roku 3’s have problems playing which results in the “loading… please wait” messages.
The solution for this until Tablo Support releases the 2.2.5 firmware is to drop down to the 720p recording setting. Or you can contact Tablo directly and have them release the beta to you for the 2.2.5 firmware. The new recording quality you will want is the ‘1080p 8 Mbps’ setting which does not record in 60 fps.
””
That’s all very interesting.
At some point in the 2.2.2 Beta, I had given up on recording 1080i broadcasts at the old 1080p HD setting, because I kept getting 30 second pauses during Chromecast playback. [Chromecast is my primary interest, not Roku.]
After much interaction with the Community and with Support, I was finally convinced that the problem was Chromecast decoder overruns, because of the high bitrate.
I switched from the old HD 1080p setting to the old Tablo 720p HD setting Aug 21 and left it that way till Sep 30.
On Sep 30 I switched to the new HD 1080 - 8 Mbps setting, and it has been that way ever since.
From Aug 21 onward I haven’t had any real problems playing recordings made from 1080i broadcasts to Chromecast; other than the slight degradation due to Tablo’s simplistic deinterlacing, an ongoing problem that probably has no resolution with the current Tablo hardware. As for recordings from 720p broadcasts, I don’t think I ever had any real problems playing these to Chromecast.
But with the level of complexity, with so many possibilities, and with changes occurring that I am sometimes unaware of, I never really quite know what is going on.
What I think happened is the following. I think that with the old HD 1080p setting: Tablo used to record 1080i broadcasts at 1080p@60fps, and 720p broadcasts at 720p@60fps.
60fps is the natural frame rate for 720p, since this is how 720p is broadcast. However, 1080i is broadcast at 30fps, so the 60fps rate Tablo was using to record 1080i broadcasts was double the natural frame rate; one unfortunate side effect being the Chromecast overruns.
Guessing a lot here, I think Tablo made two changes during the 2.2.2 Beta. First they reduced the recording frame rate for 1080i broadcasts to 30fps. I think this was done after my switch to the old Tablo 720p HD setting. I had suggested this September 9th, but I don’t think they made any changes on my account. Had I realized they had dropped the 1080 rate to 30fps, I probably could have switched back to the old 1080p HD setting at that point.
Tablo then introduced the new “HD 1080 - 8 Mbps” setting. I saw this and started using it, hoping it would solve my 1080p recording problems for Chromecast, not realizing that they had already been solved by the earlier reduction to 30 fps.
I am still running at the new “HD 1080 - 8 Mbps” setting. I suspect I could probably switch to the new “1080 HD - 10 Mbps, 720@60fps” setting, which would leave the 1080 frame rate at natural 30fps, but raise the 720 frame rate back to the natural 60fps. And all would still be okay with playback to Chromecast.
But as I said, I don’t really know. I may have the details wrong in any of the above.
@robertedisonmartin - This update is likely the reason behind exactly what you’re seeing: A Message from the CEO of Nuvyyo
The post you reference seems unrelated to my concerns. I am using Chromecast, not Roku.
I was trying to figure out what had happened to recording frame rates over the last few months, in an effort to determine whether it was safe to switch to “1080 HD - 10 Mbps, 720@60fps” for Chromecast playback. The key questions are whether 1080 is recorded at 30fps in this mode, and whether 720 used to be recorded at 60fps prior to or in the early part of the 2.2.2 Beta.
cc- @theuser86
cc- @TabloTV @TabloSupport
@robertedisonmartin - All of the current details on recording modes can be found here: https://www.tablotv.com/blog/choosing-right-tablo-recording-quality/
1080 will always be recorded at 30 fps as there are no broadcasts of 1080 @ 60 fps.
Starting on 2.2.2 (including beta) 720 (when available) was recorded @ 60 fps on the 1080 setting.
re- “1080 will always be recorded at 30 fps”
Cc @TabloTV @TabloSupport @getcashmoney @theuser86
Hold on for next FW upgrade, or move to FireTV interface? @TabloTV :
“ … 1080 will always be recorded at 30 fps as there are no broadcasts of 1080 @ 60 fps.
Starting on 2.2.2 (including beta) 720 (when available) was recorded @ 60 fps on the 1080 setting.”
If 1080i broadcasts have always been recorded at 30fps using 1080 settings, then something else changed midway through the 2.2.2 Beta.
From the very beginning, when I got the Tablo in March of 2015, I was having trouble playing back 1080i recorded at 1080p. I was getting 30 second pauses during playback, especially for soccer games. This situation continued when I switched to the 2.2.2 Beta. I finally gave up midway through the Beta, and started recording 1080i at 720p, which solved the problem; although I wasn’t happy having to drop down to the lower resolution.
Later on when Tablo introduced “HD 1080 - 8 Mbps”, I switched to this, thinking it might cure my 1080i recorded at 1080p problems. But as I now understand it, there never was any change to 1080i recorded at 1080p, which is and always had been recorded at 30fps. So, something else had changed, and had eliminated the 30 second pauses I was seeing when playing back 1080i that had been recorded at 1080p.
I had actually made another suggestion when I gave up and switched to recording at 720p. I felt that part of the problem might be unreasonably slow recovery from Chromecast overruns, and I suggested that they investigate this and try and drastically reduce the recovery time. Perhaps that is what changed.
At any rate, I misunderstood all along what was done with 720p broadcasts. It would never have occurred to me that Tablo would record 720p at 30fps. Just as it never would have occurred to me that in deinterlacing 1080i and 480i Tablo was discarding field2.
By recording 720p at half the broadcast rate, and by discarding field2 for the interlaced broadcasts, Tablo was discarding half the pixels from all types of broadcast streams.
What I purchase the device, I assumed Tablo would record and play programs at the same quality I was receiving from my antenna. This turned out not to be the case.
As shipped in early 2015, all Tablo recordings were inferior to direct play from the Antenna, because in all cases, at least half the pixels were discarded, either through simplistic deinterlacing or through frame rate reduction.
This has recently been remedied for 720p broadcasts, by allowing recording at 60fps. Recording 720p at 720p (1280x720@60fps) is the only case where the broadcast is passed through unscathed.
Here is my guess at the current situation.
Broadcasts are:
1080i 1920x[540+540]@30fps
720p 1280x720@60fps
480i 704x[240+240]@30fps
Where 1920x[540+540] is my notation to describe an interlaced frame consisting of two 540 line fields. All frame descriptions without brackets, such as 1280x720, denote non-interlaced.
For the progressive cases below, only the broadcast and recording formats are shown. But interlaced cases also show the transient deinterlaced format which Tablo’s video chip produces internally; by simple dropping field2, thus discarding half the pixels.
HD 1080 - 10 Mbps, 720@60fps
1080i => 1920x540@30 => 1920x1080@30
720p => 720p
480i => 704x240@30fps => 704x480@30fps
HD 1080 - 8 Mbps
1080i => 1920x540@30 => 1920x1080@30
720p => 1280x720@30fps
480i => 704x240@30fps => 704x480@30fps
HD 720p - 5 Mbps (recommended)
1080i => 1920x540@30 => 1280x720@30fps
720p => 1280x720@30fps
480i => 704x240@30fps => 704x480@30fps
HD 720p - 3 Mbps
1080i => 1920x540@30 => 1280x720@??fps
720p => 1280x720@??fps
480i => 704x240@30fps => 704x480@30fps
SD 480 - 2 Mbps
1080i => 1920x540@30 => 704x480@30fps
720p => 704x480@30fps
480i => 704x240@30fps => 704x480@30fps
Beware that the above is guesswork on my part.
It still worries me that I don’t understand what is going on. Every time I tried this exercise in the past, I got it wrong. And when I look at the above, I see this I still don’t know what the frame rate is 3 Mbps settings. And if I don’t understand that, maybe there are other things that I don’t understand, maybe a lot of other things.
It would make things much easier if Tablo stated exactly what they did in all cases, at a level of detail like the above.
Although the citations below are vague and possibly inaccurate, taken together they hint at what Tablo actually does, and are part of how I arrived at my guesses above.
By the way, I finally got around to trying the new HD 1080 - 10 Mbps, 720@60fps setting. It caused hangs for both 1080 and 720 recordings. So it seems it is not quite true that 1080 recordings at 10 Mbps and 8 Mbpss are the same. If I get a chance, I will compare the actual bit rates. For the moment, I dropped back all the way back to the HD 720p - 5 Mbps (recommended) setting.
Actually, I made another suggestion. I suggested that for 1080i Tablo record and send 1920x540@30 to Chromecast, which I think would eliminate the Chromecast decoder overruns. The Chromecast device could do the scaling from 1920x540@30 to 1920x1080@60.
In summary, I think Tablo should be able to record and play at original broadcast quality. It fails to do this, because of simplistic deinterlacing, and because of Chromecast and Roku issues.
Tablo should leave all deinterlacing and scaling to the TV, simply recording OTA streams as received. This would require cooperation from the streaming industry to allow passthrough.
Robert Martin
Citations –
NEW Firmware Release - 2.1.18 @TabloSupport :
“ … 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. … ”
New to Tablo: Couple comments @ChrisFix :
Ref-
http://www.cnet.com/uk/how-to/1080i-and-1080p-are-the-same-resolution/ :
“… The math is actually pretty simple: 1080 at 30fps is the same amount of data as 720 at 60 (or at least, close enough for what we’re talking about). …”
“… [for 1080i] even though there are 30 frames every second, it is actually 60 fields. Each field is 1,920x540 pixels, every 60th of a second. Of the 1,080 lines of pixels, the first field will have all the odd lines, the second field will have all the even lines. Your TV combines these together to form a complete frame of video. …”
“… If it’s done wrong, the TV instead takes each field, and just doubles the information. So you’re actually getting 1,920x540p. Many early 1080p HDTVs did this, but pretty much no modern one does. In a TV review, this is the main thing we’re checking when we test deinterlacing prowess. …”
http://www.dtvforum.info/index.php/topic/32777-de-interlacing-and-scaling-explained/ March 2006 :
“Bob De-interlacing
The most simple and common method of de-interlacing is a method known as field interpolation, or “bob de-interlacing”. Bob works by taking a single interlaced field (for an example a 540 line interlaced field of the 1080i format) and filling in the gaps via interpolation, to convert that field to a complete progressive frame. Interpolation simply looks at surrounding lines from the same field and “guesses” how to fill in the gaps between the interlaced lines. This works fine, but the big problem is that it throws away much of the available resolution. I.e. 1080i effectively becomes 540p, as only half of the available information (one interlaced field) is taken into account with the de-interlacing process. Surely there must be a better way? …”
1 Like