Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Colin_Higbie <CHigbie1@Higbie.name>
To: Nathan Owens <nathan@nathan.io>,
	Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: Frantisek Borsik <frantisek.borsik@gmail.com>,
	"starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] It’s the Latency, FCC
Date: Mon, 6 May 2024 15:22:04 +0000	[thread overview]
Message-ID: <MN2PR16MB3391A263E084AE9B74C2DE5FF11C2@MN2PR16MB3391.namprd16.prod.outlook.com> (raw)
In-Reply-To: <CALjsLJtNmJRPzBk8e8iUkCw6ihpb5Tpmd=n59uk8o3ORZo2q2Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5678 bytes --]

Nathan,

While you hit the point in your second paragraph, namely that Apple REQUIRES 25Mbps (as do others of the major streaming services, including Netflix today), your first paragraph misses it. It doesn’t matter what is POSSIBLE (unless you have the ability to persuade all streaming services to implement those technologies and ensure they work for the lion’s share of installed end-user equipment and 4K HDR streams, in which case, well done and I would agree that a lower bitrate is sufficient). The ONLY factor that matters in terms of required bandwidth to be considered a fully capable ISP service is what the market demands for the mainstream Internet services. That is 25Mbps.

As the article you linked to points out, those lower bitrates are NOT for 4K HDR (10-bit color depth per pixel). For those, even in the authors’ chosen examples, and possibly only at 8-bit color (not clear), the article claims to only get down to a low of about 17Mbps for the highest quality. I’ve seen other reports that say anything below 20Mbps will occasionally fail on particular complex scenes that don’t compress well. Add a little bit of overhead or assume some additional traffic (an important consideration, given the raison d’être of this group – reduce latency under load from multiple streams), and you’re back to 25Mbps on needed bandwidth to support multiple concurrent activities.

While I concede there is not a widely accepted standard for evaluating video quality (at least not one of which I’m aware), I dislike that Y axis (Quality) on their graphs has no metric, especially without a definition for how they define quality – is it based on lost data, % of pixels expressing compression artifacts, pixel color drift, or something else they created for the purpose of making their case? I would say that NONE of the photos shown constitute a good or excellent quality level, where all show significant compression artifacts at the high-contrast boundaries. These are distinct from natural focal problems with analog systems that are not contrast-dependent. Further, these all appear to be relatively static scenes with just a few small moving objects – the kinds of frames and scenes that compress extremely well. Again, this is why we must look to the market to determine what it needs, not individual proposals.

The article also acknowledges that the graph points represent the average, meaning some frames are better and some are worse. This is bad because with any lossy compression system, there is a (subjective) “good enough” level, where values above that don’t add much, but frames that are worse will stand out as bad. You can’t just watch the average – you’re forced to also watch the bad frames. In real-world usage, these will be the frames during high-speed image changes – explosions in action movies or a fast-panning scene), often the times when preserving fidelity are most important (e.g., you lose track of the football during the fast pan downfield, or you really want to see the detail in the X-wing fighters as the dogfight leads to explosions around them).

Further, that article is really targeting mobile usage for cellular bandwidth, where many of these viewing issues are fundamentally different from the 65” living room TV. The mobile display may offer 120Hz, but showing a movie or show at 30Hz (except for some sports) is still the standard.

Now, to be fair, I have no doubt that there exist today and will exist even more so in the future superior compression that could lower the bitrate needed at any given resolution and quality level. The one described in the article could be an important step in that direction. No doubt Netflix already has multiple economic incentives to reduce required bandwidth – their own bandwidth costs, which are a substantial % of their total operating costs, access to customers who can’t get 25Mbps connections, competition from other streaming services if they can claim that their streams are less affected by what others in the house are doing or are higher quality at any given bandwidth, etc. As noted above, however, that is all moot unless all of the major streamers adopt comparable bandwidth reduction technologies and ALSO that all major existing home equipment can support it today (i.e., without requiring people replace their TV’s or STB’s). Absent that, it’s just a technical novelty that may or may not take hold, like Betamax videotapes or HD-DVD.

On the contrary, what we see today is that the major streaming services REQUIRE users to have 25Mbps connections in order to offer the 4K HDR streams. Yes, users can lie and may find they can watch most of the 4K content they wish with only 20Mbps or in some cases 15Mbps connections, but that’s clearly not a reason why an ISP should say, “We don’t need to offer 25Mbps for our customers to be able to access any major streaming service.”

Cheers,
Colin

From: Nathan Owens <nathan@nathan.io>
Sent: Monday, May 6, 2024 9:44 AM
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: Colin_Higbie <CHigbie1@Higbie.name>; Frantisek Borsik <frantisek.borsik@gmail.com>; starlink@lists.bufferbloat.net
Subject: Re: [Starlink] It’s the Latency, FCC

You really don’t need 25Mbps for decent 4K quality - depends on the content. Netflix has some encodes that go down to 1.8Mbps with a very high VMAF:
https://netflixtechblog.com/optimized-shot-based-encodes-for-4k-now-streaming-47b516b10bbb

Apple TV has the highest bitrate encodes of any mainstream streaming service, and those do top out at ~25Mbps. Could they be more efficient? Probably…


[-- Attachment #2: Type: text/html, Size: 9564 bytes --]

  reply	other threads:[~2024-05-06 15:22 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.2877.1714641707.1074.starlink@lists.bufferbloat.net>
2024-05-02 14:47 ` Colin_Higbie
2024-05-02 19:50   ` Frantisek Borsik
2024-05-06 11:19     ` Alexandre Petrescu
2024-05-06 13:43       ` Nathan Owens
2024-05-06 15:22         ` Colin_Higbie [this message]
2024-05-14 19:23       ` Colin_Higbie
2024-05-15  6:52         ` Sebastian Moeller
2024-05-15 14:55           ` Colin_Higbie
2024-05-03  1:48   ` Ulrich Speidel
2024-05-03  7:22     ` Jeremy Austin
2024-05-03  9:02     ` Alexandre Petrescu
2024-05-03  8:29   ` Alexandre Petrescu
2024-05-03  8:34   ` Alexandre Petrescu
2024-05-06 15:42 David Fernández
  -- strict thread matches above, loose matches on Subject: below --
2024-05-06 13:21 David Fernández
2024-05-03  9:09 [Starlink] It's " David Fernández
2024-05-01 16:35 David Fernández
2024-05-01  8:41 David Fernández
     [not found] <mailman.2785.1714507537.1074.starlink@lists.bufferbloat.net>
2024-04-30 20:48 ` [Starlink] It’s " Colin  Higbie
2024-04-30 20:49   ` Colin_Higbie
2024-05-01  0:51   ` David Lang
     [not found] <mailman.2779.1714503924.1074.starlink@lists.bufferbloat.net>
2024-04-30 19:31 ` Colin_Higbie
2024-04-30 19:51   ` Eugene Y Chang
2024-04-30 21:07     ` Dave Taht
2024-04-30 21:22       ` Frantisek Borsik
2024-04-30 22:02         ` Dave Taht
2024-04-30 22:03           ` Dave Taht
2024-04-30 22:05         ` [Starlink] Fwd: " Rich Brown
2024-04-30 22:10           ` Dave Taht
2024-04-30 22:42             ` [Starlink] " Rich Brown
2024-04-30 23:06               ` Dave Taht
2024-04-30 22:31           ` Eugene Y Chang
2024-04-30 21:22       ` Eugene Y Chang
2024-04-30 21:35         ` Frantisek Borsik
2024-04-30 21:53           ` Eugene Y Chang
2024-05-01  0:54             ` David Lang
2024-05-01  7:27             ` Frantisek Borsik
2024-05-01 19:26               ` Eugene Y Chang
2024-05-14 16:05                 ` Dave Taht
     [not found] <mailman.2775.1714488970.1074.starlink@lists.bufferbloat.net>
2024-04-30 19:12 ` Colin_Higbie
2024-04-30 19:31   ` Eugene Y Chang
2024-05-01  0:33     ` David Lang
2024-05-01  0:31   ` David Lang
2024-05-01  0:40     ` [Starlink] It?s " David Lang
     [not found] <mailman.2773.1714488060.1074.starlink@lists.bufferbloat.net>
2024-04-30 18:05 ` [Starlink] It’s " Colin_Higbie
2024-04-30 19:04   ` Eugene Y Chang
2024-05-01  0:36     ` David Lang
2024-05-02  9:09     ` Alexandre Petrescu
2024-05-02  9:28       ` Ulrich Speidel
2024-04-30 20:05   ` Sebastian Moeller
2024-05-02  9:21     ` Alexandre Petrescu
     [not found] <mailman.2769.1714483871.1074.starlink@lists.bufferbloat.net>
2024-04-30 14:00 ` Colin_Higbie
2024-04-30 14:25   ` Alexandre Petrescu
2024-04-30 14:32     ` Sebastian Moeller
2024-04-30 14:40       ` Alexandre Petrescu
2024-04-30 14:45         ` Sebastian Moeller
2024-04-30 14:56           ` Alexandre Petrescu
2024-04-30 15:04             ` David Lang
2024-04-30 15:01         ` David Lang
2024-04-30  9:54 David Fernández
     [not found] <mailman.2495.1710610618.1074.starlink@lists.bufferbloat.net>
2024-03-16 19:10 ` Colin_Higbie
2024-03-16 19:32   ` Sebastian Moeller
2024-03-17 17:00   ` Alexandre Petrescu
2024-03-17 19:26     ` Frantisek Borsik
     [not found] <mailman.11.1710518402.17089.starlink@lists.bufferbloat.net>
2024-03-15 18:32 ` Colin  Higbie
2024-03-15 18:41   ` Colin_Higbie
2024-03-15 19:53     ` Spencer Sevilla
2024-03-15 20:31       ` Colin_Higbie
2024-03-16 17:18         ` Alexandre Petrescu
2024-03-16 17:21           ` Alexandre Petrescu
2024-03-16 17:36           ` Sebastian Moeller
2024-03-16 22:51             ` David Lang
2024-03-15 23:07       ` David Lang
2024-03-16 18:45         ` [Starlink] Itʼs " Colin_Higbie
2024-03-16 23:05           ` David Lang
2024-03-17 15:47             ` [Starlink] It’s " Colin_Higbie
2024-03-16 18:51         ` [Starlink] It?s " Gert Doering
2024-03-16 23:08           ` David Lang
2024-04-30  0:39   ` [Starlink] It’s " David Lang
2024-03-15  3:53 Larry Press
2024-03-15  5:33 ` Dave Taht
2024-03-15 21:14   ` Michael Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MN2PR16MB3391A263E084AE9B74C2DE5FF11C2@MN2PR16MB3391.namprd16.prod.outlook.com \
    --to=chigbie1@higbie.name \
    --cc=alexandre.petrescu@gmail.com \
    --cc=frantisek.borsik@gmail.com \
    --cc=nathan@nathan.io \
    --cc=starlink@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox