I simply checked the average bitrate of the 1080p source file.

As far as I can tell, it is others on this thread who are mistakenly analysing buffer refill speeds, so maybe you should have a word with them.

Just replying to the latest post in the thread

In reply to a post by vimto_girl:

I simply checked the average bitrate of the 1080p source file.

Where can you reliably do that? In the Flash Player youtube "statistics" or the HTML player "statistics" you get different details.

As far as I can tell, it is others on this thread who are mistakenly analysing buffer refill speeds, so maybe you should have a word with them.

Thats as may be, but its unclear when there are two players being used by YouTube and at least 3 different browsers how they all interact.

There are two 1080p source files, I downloaded the bigger and used the file size itself to determine avg video bitrate as a first step in determining sufficient speed.

Umm but that's not the question

If the OP wanted he could just download at and watch

but no hes asking about streaming

which in turn is using more than 4.5mbps due to codecs/compression.

Your post doesn't make any sense. Whether you stream the file, or download the file - the codec, compression and avg bitrate does not change.

In reply to a post by vimto_girl:

Your post doesn't make any sense. Whether you stream the file, or download the file - the codec, compression and avg bitrate does not change.

ISP performance, router performance, congestion, local WiFi etc all get involved too. As I'm aware you know its a rats nest

This wasn't epyon's point though. He claimed (nonsensically) that streaming uses more data than the file itself "due to codecs/compression".

Of course in practice you need some added margin over the file bitrate to prevent buffer underrun when streaming, and I did in fact add this to arrive at 4.5 Mbps.

One of the biggest problems with YouTube is the (paradoxical) situation of poor performing ISP CDNs at peak times. In my experience, it really is the No. 1 problem people suffer with and it is a scandal. Quite rightly, users can't understand why their 80Mbps FTTC connection buffers with YouTube. I block my ISP's YouTube CDN because it can sometimes struggle to deliver >1-2 Mbps, despite a perfect speed to "the internet" and >70 Mbps 1x TBB speedtest at the same time.

Edited by deleted (Wed 25-Mar-15 22:59:03)

In reply to a post by vimto_girl:

This wasn't epyon's point though. He claimed (nonsensically) that streaming uses more data than the file itself "due to codecs/compression".

Agreed.

Of course you need some added margin over the file bitrate in practice to prevent buffer underrun when streaming, and I did in fact add this to arrive at 4.5 Mbps.

One of the biggest problems with YouTube is the (paradoxical) situation of poor performing ISP CDNs at peak times. In my experience, it really is the No. 1 problem people suffer with and it is a scandal. Quite rightly, users can't understand why their 80Mbps FTTC connection buffers with YouTube. I block my ISP's YouTube CDN because it can sometimes struggle to deliver >1-2 Mbps, despite a perfect speed to "the internet" and TBB speediest.

YouTube itself is a strange beast. I'm not sure if they have their own CDN boxes in ISPs (like Netflix) or if Google just peer with ISPs into the Google cloud - but yes, you can get times when any YouTube video won't run even on a corporate 100/100 mbps leased line (real fibre, not consumer) connection due to the bank of servers your IP range is routed to having "problems". Its unclear as Google don't like to explain how their kit works.

YouTube streams from servers inside the major ISPs own networks, I have verified this by traffic analysis. You can block them and it will then stream from Google in the US.