If a mod is going to make allegations, I am entitled to ask for some indication where it happened and to defend myself. It's not trolling and it's not confrontation. Strange that the genuine confrontation "AS IF!" to simple informative post and the genuine personal abuse "you are snooty" get a free pass, but the tongue-in-cheek coping with it gets scrutiny.

I just re-read that BBC Video Factory article. The speed table seems in this thread to be being taken somewhat out of context. In particular things like (my underlines):-

The new profiles were designed to improve the picture quality available on devices without significantly increasing the associated bit-rate and therefore distribution cost. They were also designed to exploit the benefits of Adaptive Bit-Rate Streaming, with just noticeable changes in video resolution within an Adaptive Bit-Rate adaptation set.
...
The 50fps, 1280x720 profile, however, will be available to those with 5Mbit/s broadband connections.

Additional lower bit-rate profiles will be made available to computers on wifi. This enables video playback to continue, even when an individual's available bit-rate is reduced by users sharing a connection. These profiles will also cater for similar bit-rate restrictions on public wifi connections.

It is clear that if four users on a single 20Mbps connection were all streaming in "HD", then their picture quality would be fractionally and almost imperceptibly reduced to fit on large screen TVs, and perhaps more drastically reduced on smaller devices.

Post deleted by RobertoS 01:36

Edited by RobertoS (Fri 02-Sep-16 01:36:17)

Good point, though I am not so sure about the just noticeable bit for 50fps stuff as only a couple of modes seem to do that. Accepting of course that a lot of stuff is only 25fps to start with anyway.

https://github.com/get-iplayer/get_iplayer/wiki/mode...

There always were many profiles to choose from and if you make get_iplayer verbose you can see bitrates listed as below.

I guess these are estimates of network rates, downloaded files are a bit less, but dividing file size by duration can still be > 5mbit. By default on hls streams. get_iplayer also rips the codecs out of the ts to make mp4, so that also reduces the size slightly compared to the sizes you can see listed with get_iplayer -i [url/pid]

INFO: Found mode hlshd1: (gip_hls_iplayer_2341) hls h264 1280x720 2341kbps stream (CDN: akamai_hls_open/10)
INFO: Found mode hlshigh1: (gip_hls_iplayer_778) hls h264 640x360 778kbps stream (CDN: akamai_hls_open/10)
INFO: Found mode hlslow1: (gip_hls_iplayer_387) hls h264 512x288 387kbps stream (CDN: akamai_hls_open/10)
INFO: Found mode hlsstd1: (gip_hls_iplayer_497) hls h264 640x360 497kbps stream (CDN: akamai_hls_open/10)
INFO: Found mode hlsvhigh1: (gip_hls_iplayer_1460) hls h264 832x468 1460kbps stream (CDN: akamai_hls_open/10)
INFO: Found mode hvfhd1: (gip_hvf_iplayer_5380) hls h264 1280x720 5380kbps stream (CDN: mf_limelight_uk_hls/2)
INFO: Found mode hvfhd2: (gip_hvf_iplayer_5380) hls h264 1280x720 5380kbps stream (CDN: mf_akamai_uk_hls/1)
INFO: Found mode hvfhigh1: (gip_hvf_iplayer_956) hls h264 704x396 956kbps stream (CDN: mf_limelight_uk_hls/2)
INFO: Found mode hvfhigh2: (gip_hvf_iplayer_956) hls h264 704x396 956kbps stream (CDN: mf_akamai_uk_hls/1)
INFO: Found mode hvflow1: (gip_hvf_iplayer_340) hls h264 384x216 340kbps stream (CDN: mf_limelight_uk_hls/2)
INFO: Found mode hvflow2: (gip_hvf_iplayer_340) hls h264 384x216 340kbps stream (CDN: mf_akamai_uk_hls/1)
INFO: Found mode hvfsd1: (gip_hvf_iplayer_3043) hls h264 960x540 3043kbps stream (CDN: mf_limelight_uk_hls/2)
INFO: Found mode hvfsd2: (gip_hvf_iplayer_3043) hls h264 960x540 3043kbps stream (CDN: mf_akamai_uk_hls/1)
INFO: Found mode hvfstd1: (gip_hvf_iplayer_551) hls h264 512x288 551kbps stream (CDN: mf_limelight_uk_hls/2)
INFO: Found mode hvfstd2: (gip_hvf_iplayer_551) hls h264 512x288 551kbps stream (CDN: mf_akamai_uk_hls/1)
INFO: Found mode hvfvhigh1: (gip_hvf_iplayer_1759) hls h264 960x540 1759kbps stream (CDN: mf_limelight_uk_hls/2)
INFO: Found mode hvfvhigh2: (gip_hvf_iplayer_1759) hls h264 960x540 1759kbps stream (CDN: mf_akamai_uk_hls/1)

Edit: link to point at a specific table

Edited by deleted (Fri 02-Sep-16 17:15:55)

In a black or white world your situation would apply, but as pointed out adaptive bit rates may mean people can manage to stream without issues, hence why I was wanting to do some actual experimentation with TV connected devices

Tongue in cheek replies in a technical based topic, when not flagged explicitly as such are like a speaker making a slightly inappropriate joke, i.e. it might be Ok at a dinner where everyone knows them personally, but when broadcast to a much wider audience it becomes inappropriate.

i.e. what works when talking face to face does not always work in text based medium.

In reply to a post by MrSaffron:

That answer would mean taking a known set of hardware to various places to test it and confirm everything.

Plenty of other people are seeing time based variations with Virgin Media, but it may be that your area does not have this as its so busy, or there may just be something wrong with the cable connection

My area has never shown signs of being busy, not at least until the sudden change in TBB results, way back in May. Up until that point I consistently got my VM advertised speed on TBB. That is how this thread started, me wondering what caused the change. Since nothing changed on my premises, in terms of kit, and nothing changed at the TBB end, I can only assume there has been a VM network change. I know that re-segmenting has occurred and new Cisco or Asus cards have been installed ready for speed upgrades. Maybe as part of that my street ended up as part of a busier area, although I didn't think that VM architecture was flexible enough for a node change.

Obviously still a puzzle. Nothing is affects my quality of service, but we all hate unanswered questions don't we?

In reply to a post by RobertoS:

I just re-read that BBC Video Factory article.

It is clear that if four users on a single 20Mbps connection were all streaming in "HD", then their picture quality would be fractionally and almost imperceptibly reduced to fit on large screen TVs, and perhaps more drastically reduced on smaller devices.

The way I read that was slightly different.

What you've written suggests "adaptive bitrate streaming" means that micro-adjustments are made to encoding on the fly, to make small adjustments to the bitrate.

I believe that it means the iPlayer app can adapt the bitrate dynamically, but can only do so within the confines of a set of pre-determined encodings (so encoding isn't done on the fly). This article seems to say that.

In this way, the iPlayer app (on the STB) would stream the HD variant (1280x720 @ 5.2Mbps), but adjust down to an SD variant (eg 960x540 @ 2.9Mbps) in mid-stream if throughput (or CPU, or memory) became challenging.

I've certainly seen the iPlayer app start on a terrible quality at first, and adjust upwards to a decent quality after 10-15 seconds, so I assume it can do that downwards, and at any time.

If I'm right with that ... then I imagine 4 people trying to stream HD on 20Mbps would likely (after adjustments) find that 3 get the stream in HD while 1 gets demoted to SD.

However, my experiments showed that the bitrate is also variable, averaging out at just over 5 Mbps. That averaging might allow 4 users to keep HD, just, (good outcome) or might mean that one stream keeps switching between HD and SD (not so good outcome).

It'd be interesting to see the outcome of a real-life experiment.

I thought about that before choosing what I quoted, which are the bits your are talking about.

I think the second part is where a different profile is chosen due to the receiving kit specification, but the first is about lowering the bit rate within the chosen profile. Otherwise the mention of adaptive bit rates is meaningless, as it would simply be a question of the bitrate fixed by the profile.

I accept I could be wrong, but that was my logic.

did you read the thread I linked to?