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?
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.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.
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.
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.
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.
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).