Rumored DTV Over IP Prices Plus Two New DTV Now Packages

Status
Please reply by conversation.
Does anyone know if the bit rate on Directv Now, or the upcoming internet based Directv, will be consistent with the satellite Directv service or is it more aligned with Uverse TV?
 
Does anyone know if the bit rate on Directv Now, or the upcoming internet based Directv, will be consistent with the satellite Directv service or is it more aligned with Uverse TV?

I can't recall the bitrate used for DTV Now's 1080p and 720p streaming channels but I would say that the consensus of opinions I've read among online commenters who have had both DTV Now and DTV satellite at (or near) the same time is that the HD picture quality is better on DTV Now. I was a DTV Now beta tester a year ago, using an Apple TV 4K, and I would agree with that assessment. In fact, I would say it was the best-looking "cable TV" that I had ever personally laid eyes on. But it had been 2-3 years since I had had DTV satellite and even longer since I had had Uverse TV. At the time I had them, I thought DTV looked very good and Uverse TV looked fairly bad.

I would guess -- although who knows, really -- that the upcoming DTV streaming service will receive the same encoded streams that get served to DTV Now users. I do know that the C71 box that the upcoming service will use supports hardware decoding of the HEVC codec, just as my Apple TV 4K box does. So I would expect all content streamed from AT&T servers to that box to be done in HEVC, whether it's in HD, 4K HDR or SD.
 
The satellite (and cable) channels have to pass through a stat mux to fit in a transponder / QAM channel. Streaming channels aren't multiplexed so they don't have that secondary bandwidth trimming stage so even if Directv started with the exact same input to IP and satellite, the IP product should have a little better PQ (or a lot better if a channel is on a particular transponder that is a bit more overloaded than the rest)
 
Of course it is possible with a Roku. The problem is they'd have to maintain an app for Android TV, Roku, Apple TV, and Amazon Fire - at minimum - which is 4x the work. What's worse is that maintaining the app for all four platforms means they have to worry about all the possible hardware permutations...just look at how many different models of Roku there have been, and all the different TVs that have Roku/Fire/Android built in. They won't support them all but they need to support at least those sold in the last few years, so it ends up much worse than 4x the work. Not saying it can't be done, but if you are trying to cut costs, supporting the myriad of set top boxes out there versus one box today and never more than a handful at once ever is an easy choice.

Plus if Directv uses their own equipment they can better insure security of the content by having full control over the signal end to end, which puts it in a different category contractually than OTT streaming using a customer's equipment.
Roku has limitations of its OS that Android TV does not. Something like the full SlingPlayer app with its own interface is just not gonna happen on Roku OS, certainly not Roku's legacy (and low-end) products of even recent years. DirecTV will not be using "it's own equipment." DirecTV will be using an full, real, Android TV box branded as a DirecTV box. Encrypting the content (already achieved with services on Roku such as DirecTV Now and Sling TV) with has NOTHING to do with DirecTV's decision use AndroidTV as its platform (and, indeed, using a true, unadulterated, Android TV box). DirecTV choose Android TV because it is the ONLY OS that can allow apps to have an extremely high customization of the UI of the app/service. In other words, Android TV is the ONLY OS for an app that can allow the DirecTV's replacement streaming service to look and function nearly identical to its satellite service UI, which is VERY important since a lot of satellite customers are to be herded over to its Android TV service, and DirecTV can keep its nearly full, premium, DirecTV satellite experience, as opposed to DirecTV Now that is destined to be the cheap service.

Amazon uses forked Android, so it is not quite as expensive as supporting Roku. The real problem is that Roku OS is not the ubiquitous iOS or Android across several types of devices (which includes Amazon's forked Android). Roku OS is truly the odd bird, here. In 5 years, I really don't think Roku will be anything like it is today. There are already a number of apps I use who have abandoned Roku, but kept up with iOS, Android, and Amazon Fire (forked Android). Ironically, Roku's simplicity was its great strength, but now it is its weakness for the future. That is the cost of being first, a pioneer, having a philosophy in regards to apps to the significant limitations in technology--compared to today--that existed at the company's launch. More complicated, far more feature rich and capable competitors were vanquished because they were too complicated too close to the edge of the limitation of technology compared to Roku's simplicity of purpose and OS design that kept things lightweight. Now that we can support more complexity of OS, Amazon (forked Android) and Android TV are gonna wipe their bum with Rokus. Fire's and Android TV's UI experience is, often, superior to Roku's, but sometimes coming to the party a little late has its advantages.
 
Last edited:
Roku has limitations of its OS that Android TV does not. Something like the full SlingPlayer app with its own interface is just not gonna happen on Roku OS, certainly not Roku's legacy (and low-end) products of even recent years. DirecTV will not be using "it's own equipment." DirecTV will be using an full, real, Android TV box branded as a DirecTV box. Encrypting the content (already achieved with services on Roku such as DirecTV Now and Sling TV) with has NOTHING to do with DirecTV's decision use AndroidTV as its platform (and, indeed, using a true, unadulterated, Android TV box). DirecTV choose Android TV because it is the ONLY OS that can allow apps to have an extremely high customization of the UI of the app/service. In other words, Android TV is the ONLY OS for an app that can allow the DirecTV's replacement streaming service to look and function nearly identical to its satellite service UI, which is VERY important since a lot of satellite customers are to be herded over to its Android TV service, and DirecTV can keep its nearly full, premium, DirecTV satellite experience, as opposed to DirecTV Now that is destined to be the cheap service.

Amazon uses forked Android, so it is not quite as expensive as supporting Roku. The real problem is that Roku OS is not the ubiquitous iOS or Android across several types of devices (which includes Amazon's forked Android). Roku OS is truly the odd bird, here. In 5 years, I really don't think Roku will be anything like it is today. There are already a number of apps I use who have abandoned Roku, but kept up with iOS, Android, and Amazon Fire (forked Android). Ironically, Roku's simplicity was its great strength, but now it is its weakness for the future. That is the cost of being first, a pioneer, having a philosophy in regards to apps to the significant limitations in technology--compared to today--that existed at the company's launch. More complicated, far more feature rich and capable competitors were vanquished because they were too complicated too close to the edge of the limitation of technology compared to Roku's simplicity of purpose and OS design that kept things lightweight. Now that we can support more complexity of OS, Amazon (forked Android) and Android TV are gonna wipe their bum with Rokus. Fire's and Android TV's UI experience is, often, superior to Roku's, but sometimes coming to the party a little late has its advantages.


There's no difference between Directv commissioning OEMs to manufacture boxes running Linux like the C61, and Directv commissioning OEMs to manufacture boxes running Android - which runs the same Linux kernel. It is stupid to claim that they are just "branded" as a Directv box. The C71KW is every bit as much a Directv box as the C61, they are being manufactured to Directv specs not bought on the open market and relabeled. They just run a different OS, because the apps they want it to run are already out there, meaning it is cheaper for them since they don't need to absorb any of the app development costs beyond their own GUI.
 
There's no difference between Directv commissioning OEMs to manufacture boxes running Linux like the C61, and Directv commissioning OEMs to manufacture boxes running Android - which runs the same Linux kernel. It is stupid to claim that they are just "branded" as a Directv box. The C71KW is every bit as much a Directv box as the C61, they are being manufactured to Directv specs not bought on the open market and relabeled. They just run a different OS, because the apps they want it to run are already out there, meaning it is cheaper for them since they don't need to absorb any of the app development costs beyond their own GUI.

Well, yes and no. If the new C71 box was running open-source Linux or their own forked Android (like Fire TV does), then it would be just like any other box that AT&T has commissioned an OEM to manufacture for them, with AT&T fully in control. But instead, the C71 is running Google's Android TV Operator Tier as the operating system, so it must conform to certain standards that Google stipulates. Pretty much the entire code base is from Google, and of course it must contain the Google Play Store and other pre-installed Google apps (e.g. YouTube) and features (e.g. Google Assistant, Chromecast built-in). It's mainly just the home screen UI and the remote control that AT&T gets to customize to a certain extent.

So while all of the existing boxes for DTV satellite can be thought of as simply being "from DirecTV/AT&T", the C71 is really jointly from AT&T and Google.
 
Given the way ATT is running DTV, I would not be surprised if they don't Internet stream the same stat muxed satellite streams to avoid buying new encoders and paying people to operate them.

The satellite (and cable) channels have to pass through a stat mux to fit in a transponder / QAM channel. Streaming channels aren't multiplexed so they don't have that secondary bandwidth trimming stage so even if Directv started with the exact same input to IP and satellite, the IP product should have a little better PQ (or a lot better if a channel is on a particular transponder that is a bit more overloaded than the rest)
 
Given the way ATT is running DTV, I would not be surprised if they don't Internet stream the same stat muxed satellite streams to avoid buying new encoders and paying people to operate them.

I doubt they will, only because they will want to use HEVC to encode everything for the IP product. Using MPEG4 like Directv does for HD would require 50-100% more bandwidth for the same PQ. That'll add up fast once they have millions of customers for it.

But if it turns out they are distributing in MPEG4 when the IP product launches then you are probably right. I don't necessarily think that would be a bad thing - it is just as likely they would compress MORE for the IP product to save bandwidth than compress less and give superior PQ. They only pay the cost of the bandwidth for satellite once, with IP they pay it again and again for every customer watching a given channel. At least doing that would mean there's no reason PQ-wise to prefer either option.
 
We also know that their IP streams for DTV Now (and presumably Watch TV and any other current or future OTT app/service) are adjustable bitrate, meaning that the bitrate/resolution will automatically shift to a lower or higher level from moment to moment depending on the speed and quality of your internet connection. Having that kind of flexibility in the streaming bitrate may require a separate encoding process for live channels versus what is done for satellite, where the bitrate is what it is for any and all receivers.

As for slice1900's point about bandwidth costs adding up for each viewer -- since each viewer means an additional unicast stream -- that's true, although most of those costs would be borne by other network providers (e.g. Comcast, Charter, Verizon, etc.) for viewers that are connected to the internet through them rather than through AT&T (whether home broadband or mobile). As for those viewers who are on an AT&T connection, I would imagine that AT&T would seek to reduce some of the video traffic (and therefore cost) they generate by employing multicast streams where it makes sense (i.e. on the most popular live linear channels) on their own network. You may be thinking "But multicast can only be done on a 'managed IPTV' system like Uverse TV, not on OTT services." But that's not true. A network provider can dynamically apply multicast to video traffic in their own network if the end customer's hardware -- either their internet gateway or their viewing device (e.g. STB) supports it. The French company Broadpeak offers one such solution with their "nanoCDN multicast ABR" platform. It can be enabled within Android TV STBs by simply installing Broadpeak's own app on the device. It's certainly possible that AT&T already has or will deploy this or a similar solution in their C71 STB and/or AT&T Fiber/Internet gateway devices.
 
We also know that their IP streams for DTV Now (and presumably Watch TV and any other current or future OTT app/service) are adjustable bitrate, meaning that the bitrate/resolution will automatically shift to a lower or higher level from moment to moment depending on the speed and quality of your internet connection. Having that kind of flexibility in the streaming bitrate may require a separate encoding process for live channels versus what is done for satellite, where the bitrate is what it is for any and all receivers.

As for slice1900's point about bandwidth costs adding up for each viewer -- since each viewer means an additional unicast stream -- that's true, although most of those costs would be borne by other network providers (e.g. Comcast, Charter, Verizon, etc.) for viewers that are connected to the internet through them rather than through AT&T (whether home broadband or mobile). As for those viewers who are on an AT&T connection, I would imagine that AT&T would seek to reduce some of the video traffic (and therefore cost) they generate by employing multicast streams where it makes sense (i.e. on the most popular live linear channels) on their own network. You may be thinking "But multicast can only be done on a 'managed IPTV' system like Uverse TV, not on OTT services." But that's not true. A network provider can dynamically apply multicast to video traffic in their own network if the end customer's hardware -- either their internet gateway or their viewing device (e.g. STB) supports it. The French company Broadpeak offers one such solution with their "nanoCDN multicast ABR" platform. It can be enabled within Android TV STBs by simply installing Broadpeak's own app on the device. It's certainly possible that AT&T already has or will deploy this or a similar solution in their C71 STB and/or AT&T Fiber/Internet gateway devices.

CDNs charge by total traffic so if they can use HEVC and cut their bitrate by 40% or whatever that's a huge incentive to use HEVC. CDNs handle the bandwidth shaving for less than perfect network conditions, that isn't done on Directv's end (imagine how impossible a task that would be with millions of endpoints!)

You're right about multicast being possible for AT&T's internal network, the gotcha is that AT&T would need their own equipment in the customer's house - no more using your own router since they won't all support multicast properly (especially for wireless) so I really doubt that's something they'd want to rely on. Maybe they can convert multicast to multiple unicast streams inside the DSL modem / fiber bridge.
 
CDNs charge by total traffic so if they can use HEVC and cut their bitrate by 40% or whatever that's a huge incentive to use HEVC.

Yes.

CDNs handle the bandwidth shaving for less than perfect network conditions, that isn't done on Directv's end (imagine how impossible a task that would be with millions of endpoints!)

First, AT&T operates their own CDN services, although I imagine they may also use third-party CDNs to deliver their OTT content, particularly to end users that aren't on an AT&T network connection.

Second, I'm not sure that all bitrate adjusting is handled simply by the CDN. Take a look, for instance, at Netflix's encoding practices (including their "bitrate ladder"), whereby they prepare multiple different encodes for each title in order to be able to deliver an optimal stream depending on the endpoint viewing device as well as network conditions. Granted, that's pre-encoded on-demand content, not live content that's encoded on-the-fly, but still, it's possible that DTV Now's delivery system requires more than one on-the-fly encoding of live channels in their ingestion system (e.g. 1080p @ 10 Mbps, 720p @ 5 Mbps, 720p @ 3 Mbps, 480p @ 1 Mbps, etc.), which would mean that they couldn't simply use the same encoding/ingestion system that they have in place for DTV satellite distribution (which is the idea that sparked all this back-and-forth in the last few posts).

You're right about multicast being possible for AT&T's internal network, the gotcha is that AT&T would need their own equipment in the customer's house - no more using your own router since they won't all support multicast properly (especially for wireless) so I really doubt that's something they'd want to rely on. Maybe they can convert multicast to multiple unicast streams inside the DSL modem / fiber bridge.

All AT&T home internet services (Fiber, FTTN, DSL) require use of an AT&T-supplied gateway, which, as you say, could be firmware-enabled to convert AT&T's own multicast video streams to unicast streams for distribution on the in-home network. Also, the C71 STB itself could contain software that enables it to directly access AT&T's multicast streams (assuming that AT&T is the internet provider) without the need for the AT&T gateway to first convert to unicast. But assuming such software isn't included in the C71 box itself, then it's possible that customers who put their AT&T gateway into DMZ/passthrough mode in order to use their own router would not be able to access multicast video from AT&T; I'm not sure. But, even so, such cases would likely constitute a very small percentage of viewers and therefore not make a significant impact on overall network traffic.
 
Granted, that's pre-encoded on-demand content, not live content that's encoded on-the-fly, but still, it's possible that DTV Now's delivery system requires more than one on-the-fly encoding of live channels in their ingestion system (e.g. 1080p @ 10 Mbps, 720p @ 5 Mbps, 720p @ 3 Mbps, 480p @ 1 Mbps, etc.), which would mean that they couldn't simply use the same encoding/ingestion system that they have in place for DTV satellite distribution (which is the idea that sparked all this back-and-forth in the last few posts).

I doubt they downrez anything, they'd just shave bits off and lower the quality if a channel is e.g. 1080i (thus carried as 1080p30 for streaming) not convert it to 720p or 480p.
 
Status
Please reply by conversation.

Users Who Are Viewing This Thread (Total: 0, Members: 0, Guests: 0)

Who Read This Thread (Total Members: 2)