The YouTube TV Thread

Similar, although I’m not sure how Hulu handles letting users outside the home area set up different profiles.

I’ve let rocky use my YouTube tv as a friend “account” and we both had our own locals many hundreds of miles apart.

Don't tell anyone but I share my account with a young family member different time-zone just starting out and college debt that's insane. They limit streams to 3 however.
 
I have friends that have done that. They have OTA with a Tivo and buy other shows they like. No subscriptions at all.

Not everyone is addicted and has to have TV. Most people on this site don't seem to get that. They don't realize that you can drop TV all together. Life does go on.

I can't believe people here think that cord cutters will eventually go back to paying high cable and satellite prices. Not everyone has to have TV.

Possible. Prices will definitely continue to go up on all the platforms, streaming and traditional.

But, the savings have been realized for me, so I am happy with what I have saved so far, and as far as i can see, will continue to save for some time.

When it comes to a certain price point, tv just isn’t worth it to me, no matter the delivery method.

Once it loses the value to me, I’ll just drop it and buy what few shows I really want to see.

Sent from my SM-G950U1 using the SatelliteGuys app!
 
Most people on this site don't seem to get that. They don't realize that you can drop TV all together.
Given that acquiring TV programming is pretty much the point of this site, that shouldn't come as a shocker.

At some point I hope that we spend less time following the "social influencers" and get back to something (pretty much anything, really) a whole lot more enriching.
 
I’m ok with the price increase with the new channel additions. I had been missing HGTV and the Discovery Channels.
My line up is now complete. If I had about the same package and 3 dvr’s with Directv, I would be paying well north of $120!
 
  • Like
Reactions: Jhon69 and Gobucks
It's not a shocker but people do need to realize there is more to life then TV. It is possible to drop it.

Rising prices make it a whole lot easier too.
Given that acquiring TV programming is pretty much the point of this site, that shouldn't come as a shocker.

At some point I hope that we spend less time following the "social influencers" and get back to something (pretty much anything, really) a whole lot more enriching.

Sent from my SM-G950U1 using the SatelliteGuys app!
 
One possible silver lining out of all of this: YoutubeTV has been operating at a loss since its inception - this price increase might actually turn that around and prevent YoutubeTV from ending up on this list: Killed by Google

I’ve been streaming 2 feeds of NHL playoffs from USA / NBCSN all evening, and what’s surprising is this is the first service that hasn’t crapped out during NHL playoffs in the time I’ve been messing around with streaming. I had a miserable time with Vue 2 years ago, and Hulu Live buffered like crazy when I tried to use it for the playoffs last year. The compression artifacts on DirecTV (satellite) NBCSN convinced me to give another service a try this year, and so far YoutubeTV is showing that Google’s deep infrastructure capacity makes a huge difference.
 
I’m ok with the price increase with the new channel additions. I had been missing HGTV and the Discovery Channels.
My line up is now complete.

Yep, not having Food Network made switching from Vue a no way in my house because of my wife, just like Hulu not having AMC and BBC makes that a no from me.

Going to give it a try next week to see if it is much better then Vue as far as the picture goes.

If I had about the same package and 3 dvr’s with Directv, I would be paying well north of $120!

Just went to Dish’s site, to get the same level of channels plus a DVR and 2 other boxes the price would be $100 a month for the first 2 years, I rather pay the $50.




Sent from my iPad using SatelliteGuys
 
The compression artifacts on DirecTV (satellite) NBCSN convinced me to give another service a try this year, and so far YoutubeTV is showing that Google’s deep infrastructure capacity makes a huge difference.
While Google has great gobs of data mining infrastructure, they aren't particularly well endowed with streaming capacity. Amazon is the service that is loaded for bear in that market space.

I'm lead to believe that Google Play is really just an authentication service for much of the video programming they offer.
 
While Google has great gobs of data mining infrastructure, they aren't particularly well endowed with streaming capacity. Amazon is the service that is loaded for bear in that market space.

I'm lead to believe that Google Play is really just an authentication service for much of the video programming they offer.
I can't speak to Google Play, but YoutubeTV is highly integrated into the Youtube CDN infrastructure. Packet captures confirm it's using the same IP space as regular Youtube for streaming sources.

One other interesting point of integration: your YoutubeTV watching history is integrated into your standard Youtube watch history.
 
One possible silver lining out of all of this: YoutubeTV has been operating at a loss since its inception - this price increase might actually turn that around and prevent YoutubeTV from ending up on this list: Killed by Google

I'd been hoping YTTV would add NFL Network, but wasn't sure if they could at current prices. So hopefully there's some room now to add a couple other channels (besides OWN) in the coming year.

This whole $15 price hike would've been much easier for me to accept if they had added at least one channel I'd actually watch, along with a new feature, like 5.1 audio on all content when available.
 
I can't speak to Google Play, but YoutubeTV is highly integrated into the Youtube CDN infrastructure. Packet captures confirm it's using the same IP space as regular Youtube for streaming sources.
Something that perhaps isn't much of a consideration with YouTube proper is the ability to transcode/down-convert on the fly. I reason that this is critically important to YTTV.

Have you determined what the typical delay (if measurable) is with "live" programming?
 
Something that perhaps isn't much of a consideration with YouTube proper is the ability to transcode/down-convert on the fly. I reason that this is critically important to YTTV.
Transcoding into multiple bitrates is definitely important, but you only do it once and then replicate the streams out to your severs at the edge that fulfill client requests.

All of the streaming services use MPEG DASH or HTTP Live Streaming (HLS), including Youtube. They get a master feed either via satellite or network ingestion, they then process that feed and break it down into 2-10 second segments of each of the following components:

1) Encryption Keys
2) Audio Tracks
3) Video tracks
4) Subtitles

When you select a channel to start streaming, the player app (javascript in browser, or streaming box app) makes the request to the API front-end and gets a manifest file back. The manifest file contains links to APIs that generate M3U8 playlists which have links to fetch all of the smaller segments. The manifest file looks like this: Paste2.org - Viewing Paste 8G84cPzX

Even if you aren't a programmer, you can probably skim through that XML and start to see what's going on.

SegmentTimeline - This defines the start time in UTC (segmentIngestTime) and indexes the time segments that the client is able to grab. In this example most of these are 5 second segments d="5005" for duration 5005ms.

AdaptationSet - This defines the segments of media content.
The first stanza has Primary audio (Primary.5) with 2 DRM definitions (playready and widevine).
The second stanza is for Secondary audio.
The third stanza starts defining the video feeds available:
Code:
<Representation id="142" codecs="avc1.4d4015" width="426" height="240" startWithSAP="1" maxPlayoutRate="1" bandwidth="258000" frameRate="30">
 <Representation id="143" codecs="avc1.4d401e" width="640" height="360" startWithSAP="1" maxPlayoutRate="1" bandwidth="646000" frameRate="30">
<Representation id="144" codecs="avc1.4d401f" width="854" height="480" startWithSAP="1" maxPlayoutRate="1" bandwidth="1171000" frameRate="30">
<Representation id="161" codecs="avc1.42c00b" width="256" height="144" startWithSAP="1" maxPlayoutRate="1" bandwidth="124000" frameRate="30">
<Representation id="145" codecs="avc1.4d401f" width="1280" height="720" startWithSAP="1" maxPlayoutRate="1" bandwidth="2326000" frameRate="30">
<Representation id="146" codecs="avc1.640028" width="1920" height="1080" startWithSAP="1" maxPlayoutRate="1" bandwidth="4347250" frameRate="30">
<Representation id="384" codecs="avc1.4d4020" width="1280" height="720" startWithSAP="1" maxPlayoutRate="1" bandwidth="3481000" frameRate="60">
<Representation id="385" codecs="avc1.64002a" width="1920" height="1080" startWithSAP="1" maxPlayoutRate="1" bandwidth="5791000" frameRate="60">
The fourth stanza has the closed caption definitions.​

When your client starts streaming, it grabs from the top playlist that matches any bitrate, resolution, or codec limitations that have been placed on the client, and tries to fill the buffer with several ~5s content segments as quickly as possible (video, audio, and captions are muxed together locally and played back "gapless"). It monitors the download rate of the ~5 second clips and if it determines it isn't achieving high enough throughput to keep the buffer full it will down-select a m3u8 playlist that has a target bitrate (bandwidth= statement) that matches its calculated available bandwidth.

Have you determined what the typical delay (if measurable) is with "live" programming?
It's 30-40 seconds behind a side-by-side DirecTV live feed (I think this is variable by how good of an initial "burst" download you get). I don't think it's possible for that to ever improve with this architecture. On the supply side you have encoding delay to produce segment files and apply local DRM, and those files have to be distributed out to your CDN servers at the edge so that clients can request them. On the client side your client still needs to fetch at least 10-15 seconds of video to have enough data to calculate effective bandwidth and have enough content in the buffer to maintain continuous playback.

I've said it before - when you break down the mechanics of how this all works, it's sort of amazing that live video over the Internet is even a thing.

Edit: Side note, on the manifest file you'll notice that all of the video content is being served from the googlevideo.com domain.
 
Last edited:
One benefit for me having YTTV and Philo is,now YTTV has the Travel Channel's West Feed,while Philo has the Travel Channel's East Feed.
I have not had time yet to check the rest YTTV additions compared to Philos.
So far I consider YTTV's additions a benefit and plan to keep both services.
 
I'll be dropping Philo once the 6-month special ends now that YTTV has raised rates and added a few channels I actually watch. Philio UI hasn't been a big hit with us.
 
While Google has great gobs of data mining infrastructure, they aren't particularly well endowed with streaming capacity. Amazon is the service that is loaded for bear in that market space.

I'm lead to believe that Google Play is really just an authentication service for much of the video programming they offer.

Google owns way more fiber than Amazon -- they bought a ton during the recession, and they have their own public cloud which rivals AWS in scope, plus they have POPs all over the world. There are at least 3 in a 250 mile radius from my home. I would actually say Google has the advantage in this space due to the amount of fiber they own. They are less dependent on intermediate backbone providers than Amazon. It all depends on the architecture the different services are using for their live streaming functionality. Also, plenty of stuff is live streamed on YouTube. Of course, I don't know whether they are using the same platform for that as YTTV.
 
Transcoding into multiple bitrates is definitely important, but you only do it once and then replicate the streams out to your severs at the edge that fulfill client requests.
...
It's 30-40 seconds behind a side-by-side DirecTV live feed (I think this is variable by how good of an initial "burst" download you get). I don't think it's possible for that to ever improve with this architecture. On the supply side you have encoding delay to produce segment files and apply local DRM, and those files have to be distributed out to your CDN servers at the edge so that clients can request them.
DIRECTV and DISH SD run behind terrestrial by around 7-10 seconds (more for locals as there are often two round trips to the Clarke Belt) but they have only one bitrate. The DBS providers do have to pack the channels into a transponder but that's perhaps close to real-time.

I expect that the whole unicast thing is going to start hurting badly as the number of those streaming increases and they're going to have to come up with something more localized or, heaven forbid, support buffering in the streaming devices. I know they'd love to multicast, but I think the cow is out of the barn with respect to pausing live TV.

I think it is safe to assume that any DRM happens in near-real time.
 
Google owns way more fiber than Amazon -- they bought a ton during the recession, and they have their own public cloud which rivals AWS in scope, plus they have POPs all over the world.
Fiber is the pipe, but there's a huge amount of infrastructure required to fill the pipe. As SpaethCo notes, it takes a fairly good chunk of time from receiving something to being able to spit it back out with YouTube's secret sauce on it.
 

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

Latest posts