HDHomeRun tuners from SiliconDust don't actually do any transcoding (except for the EXTEND models, but the CONNECT series and other tuners all just stream in native format) – they just send the raw MPEG-2 data stream to the decoder/app. In the case of Apple TV, this is perfectly fine, as the hardware supports this (i.e. native app or some other tuning app such as Channels or Plex). I suspect the real issue is that TiVo is using the same decode engine across all platforms, which includes Roku, and of which Roku unfortunately does
NOT currently support
native MPEG-2 decode. So TiVo is making the rather poor and lazy decision to go with the lowest common denominator.
Somewhat correct... The lack of MPEG-2 support on iOS/tvOS/macOS
was mostly a software limitation. iOS/tvOS 11 and macOS 10.13 finally opened up native MPEG-2 decode (don't recall atm if this is just a sw decoder or if it is done in hw, but in either case, the devices capable of running these OS' are easily able to decode all ATSC streams without too much effort). As alluded to above, I can think of two reasons why TiVo is making the decision to transcode the content to H.264 rather than just stream the native MPEG-2 (which has been proven by numerous other apps to be quite possible on the Apple TV):
- Lowest common denominator if they are using the same decode engine across all platforms
- 1080i content – since the majority of ATSC channels are in 1080i format, these channels would have to be deinterlaced when displayed through a STB such as the Apple TV to look 'right' (i.e. no combing artifacts) on people's TVs. There are two methods to accomplish this: a) do what SiliconDust does in their app and deinterlace in the app – this is usually just a cheap field-drop deinterlacer employed so the net result is only 1080p30 at best; b) do the deinterlace in hardware during transcode at the server side – this is what it sounds like TiVo is doing, but they are doing it in the most bare-bones manner. My guess is that they are first dropping one of the fields from 1080i content and then scaling down the horizontal and slightly scaling up the vertical. For 720p native content, they are likely just dropping every other frame.
In both cases, as long as the TV isn't larger than probably 50-55", and the content is something like movies or primetime TV, it won't be a huge issue for most (since the vast majority of this type of content is only native 24fps, so encoding or displaying any more frames doesn't make much sense, as the TV or STB will reinsert those repeated frames on display to match the native refresh rate). But if the TV is 65" or larger, and/or the content is sports, then there will be a very noticeable degradation to what we all know how broadcast TV
should look.
The real solution would be for TiVo to maintain the source picture properties for native 720p channels, as this is already progressive and 60fps. For 1080i, they should be doing a field separation and ordering, then scaling the resulting 1920x540 image to 1280x720 at 60fps. But I suspect that there may be some truth to their comment that there is a lack of resources available on their current boxes to support this 1080i conversion in real-time as a JITT (just-in-time-transcoder service).
[doublepost=1548430784][/doublepost]
The split is closer to 70/30 for 1080i vs 720p, but this is right on. I know of only a few lesser-subscribed channels that offer native 1080p broadcast, and even then, those channels aren't always passed on by the SPs (service provider) to their customers at native 1080p. Regarding the MPEG-2 aspect of things, if a channel reaches your home in HD MPEG-2, then that is usually a very high quality signal (by broadcast standards at least). However, most SPs don't deliver in MPEG-2, as they do not have enough bandwidth on their network or just don't want to deliver that much bandwidth through their network (its pretty costly). So they take the source signal they receive from the broadcaster and transcode it into a much lower bit rate H.264 stream. Not only that, some SPs employ a form of transcoding called statmuxing, whereby multiple channels are put into a pool and a 'overseer' controller tries to make decisions in real-time as to how to best allocate available bit rate assigned to the pool to each channel. This is precisely why you may see noticeable artifacting on some channels on most traditional cable delivery services, as there may be up to 12 channels or more fighting for bit rate in a 38Mbps pool.