From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 666583CBD6 for ; Mon, 6 May 2024 11:42:40 -0400 (EDT) Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2dac77cdf43so26272531fa.2 for ; Mon, 06 May 2024 08:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715010159; x=1715614959; darn=lists.bufferbloat.net; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=9qXyOMLd+oH+MUsUCWANdD1gJnIv1HG8spRTYkVWBTw=; b=IaHG6/Hj2cgxBf5sulOGJI9V+pKIof+93hgYzSDa9pr5eWoQB3rql7yabf/K92yczS SafsmZmSVV1Bf2XyPmdizUsF6VCArNgi0DBmfgvgA0Zjb2zbZgviG7kvyjpBITPqMEwa cgenuwuLVwUSR93IhdLiYz2wZLhTBQmEAn5pdn41JQvhCCESC1Wt5/no4DLwRXKOuWL8 3n2HnxWeuVqI0GCdcr1lNQvsyW/fnDYq6+ASU8UgKsxkIyKsjzYO0yyJeBnUyR94NY8V R6STBO7Vz4kq+/cY+r/tgw3ejiUBLlMCrFxLr7c/s2/S++1182fycMNGFu/NS/tg/t1Z KEDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715010159; x=1715614959; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=9qXyOMLd+oH+MUsUCWANdD1gJnIv1HG8spRTYkVWBTw=; b=Ov4mWS7zRSJBvsgZSVWdZRn2ma9psW3qRI66yfq9lUNklynp7ulQLSJQL1pkVZLWg9 JpNbD1LVIBWaV2WP1GgRWfJHGYTjRqjZvbVYTJP4XLTGbMG5IPZJg2hA50t1EzXRbE81 JU1tlqzZ7khA+yaFjsXtF4qdAE7FVEUl5KBIZRpAvmrY0RJ2fwUWb75t3MgkxUDGKcbo /o7fxe2y03pDkCrgTN1h5djeMsUwzZ49/yuWaPDVLGgAYmoSd90snTM8OdYpaLhjD1+G tZDgo0hkImbDzwnLwrkxc4WhHX0FUmxXfyNo/1ckYtOAQuwS81Z+eWDaMYyf7ygZhrHQ 29Zg== X-Gm-Message-State: AOJu0Yx9vi/BDY8j9NUfBudJbMy4VnJjQZZRQ4YRuduyLkKIAbKXWOSv tzgA4YcWXXOvGrn2x0zIGJQ8CqoU49yIznVItCeYoBDtGvrOAjvxTWCKcaM6Lj70tVEIJ9jUs3f V2px4oQnHDBImYc2wKIbx2Nnn2oGWmH/bw0am0g== X-Google-Smtp-Source: AGHT+IFtBCeCXEgVFqrk9pw7fN3YpvgscPAban5oXsof7yLhZFIHpy/VXl90ErhAunXmGu2gyAdJGoc5qwTqwr0yM9M= X-Received: by 2002:a2e:b0fb:0:b0:2df:6fd5:1475 with SMTP id h27-20020a2eb0fb000000b002df6fd51475mr8775688ljl.28.1715010158330; Mon, 06 May 2024 08:42:38 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?David_Fern=C3=A1ndez?= Date: Mon, 6 May 2024 17:42:01 +0200 Message-ID: To: starlink Content-Type: multipart/alternative; boundary="000000000000460d4e0617caeb46" Subject: Re: [Starlink] =?utf-8?q?It=E2=80=99s_the_Latency=2C_FCC?= X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2024 15:42:40 -0000 --000000000000460d4e0617caeb46 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable " there is not a widely accepted standard for evaluating video quality (at least not one of which I=E2=80=99m aware" What about ITU-T BT.500? https://www.itu.int/rec/R-REC-BT.500 Well, AFAIK, Netflix invented VMAF because ITU methods are very expensive to implement, not automated and PSNR was not good enough. "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" Yes, 25 Mbit/s is for HEVC (H.265), but the successor H.266 (VVC) is already here and it reduces the data rate required by ~20%, but it seems that Netflix may prefer AV1, which is between HEVC and VVC in terms of performance. Regards, David F. Date: Mon, 6 May 2024 15:22:04 +0000 From: Colin_Higbie To: Nathan Owens , Alexandre Petrescu Cc: Frantisek Borsik , "starlink@lists.bufferbloat.net" Subject: Re: [Starlink] It=E2=80=99s the Latency, FCC Message-ID: < MN2PR16MB3391A263E084AE9B74C2DE5FF11C2@MN2PR16MB3391.namprd16.prod.outlook.= com > Content-Type: text/plain; charset=3D"utf-8" 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=E2=80=99t matter w= hat is POSSIBLE (unless you have the ability to persuade all streaming services to implement those technologies and ensure they work for the lion=E2=80=99s sh= are 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=E2=80= =99 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=E2=80=99ve seen other reports that say anything below 20Mbps will occasio= nally fail on particular complex scenes that don=E2=80=99t compress well. Add a l= ittle bit of overhead or assume some additional traffic (an important consideration, given the raison d=E2=80=99=C3=AAtre of this group =E2=80=93= reduce latency under load from multiple streams), and you=E2=80=99re back to 25Mbps on needed ba= ndwidth 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=E2=80=99m aware), I dislike that= Y axis (Quality) on their graphs has no metric, especially without a definition for how they define quality =E2=80=93 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 =E2=80=93 the kinds of frames a= nd 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) =E2=80=9Cgood enough= =E2=80=9D level, where values above that don=E2=80=99t add much, but frames that are worse w= ill stand out as bad. You can=E2=80=99t just watch the average =E2=80=93 you=E2= =80=99re forced to also watch the bad frames. In real-world usage, these will be the frames during high-speed image changes =E2=80=93 explosions in action movies or a fast-pa= nning 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=E2=80=9D living room TV. The mobile display may offer 120Hz, bu= t 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 =E2= =80=93 their own bandwidth costs, which are a substantial % of their total operating costs, access to customers who can=E2=80=99t get 25Mbps connectio= ns, 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=E2=80=99s= or STB=E2=80=99s). Absent that, it=E2=80=99s 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=E2=80=99s clearly not a reason why an ISP should say, =E2=80=9CWe don= =E2=80=99t need to offer 25Mbps for our customers to be able to access any major streaming service.= =E2=80=9D Cheers, Colin --000000000000460d4e0617caeb46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
" there is not a widely accepted standard for evaluating video quality (at l= east not one of which I=E2=80=99m aware"

What= about ITU-T BT.500? https= ://www.itu.int/rec/R-REC-BT.500
Well, AFAIK, Netflix invented= VMAF because ITU methods are very expensive to implement, not automated an= d PSNR was not good enough.

"I have no doubt = that there exist today and will exist even more so in=20 the future superior compression that could lower the bitrate needed"
Yes, 25 Mbit/s is for HEVC (H.265), but the successor H.266 (VVC) = is already here and it reduces the data rate required by ~20%, but it seems= that Netflix may prefer AV1, which is between HEVC and VVC in terms of per= formance.

Regards,

Da= vid F.

Date: Mon, 6 May 2024 15:22:04 +0000
From: Colin_Higbie <CHigbie1@Higbie.name>
To: Nathan Owens <= nathan@nathan.io>, Alexandre Petrescu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <alexandre.petrescu@gmail.com>
Cc: Frantisek Borsik <frantisek.borsik@gmail.com>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "starlink@lists.bufferbloat.net" <starlink@l= ists.bufferbloat.net>
Subject: Re: [Starlink] It=E2=80=99s the Latency, FCC
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <MN= 2PR16MB3391A263E084AE9B74C2DE5FF11C2@MN2PR16MB3391.namprd16.prod.outlook.co= m>

Content-Type: text/plain; charset=3D"utf-8"

Nathan,

While you hit the point in your second paragraph, namely that Apple=20 REQUIRES 25Mbps (as do others of the major streaming services, including Netflix today), your first paragraph misses it. It doesn=E2=80=99t matter = what=20 is POSSIBLE (unless you have the ability to persuade all streaming=20 services to implement those technologies and ensure they work for the=20 lion=E2=80=99s share of installed end-user equipment and 4K HDR streams, in= =20 which case, well done and I would agree that a lower bitrate is=20 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=20 for 4K HDR (10-bit color depth per pixel). For those, even in the=20 authors=E2=80=99 chosen examples, and possibly only at 8-bit color (not cle= ar),=20 the article claims to only get down to a low of about 17Mbps for the=20 highest quality. I=E2=80=99ve seen other reports that say anything below 20= Mbps=20 will occasionally fail on particular complex scenes that don=E2=80=99t comp= ress=20 well. Add a little bit of overhead or assume some additional traffic (an important consideration, given the raison d=E2=80=99=C3=AAtre of this grou= p =E2=80=93 reduce latency under load from multiple streams), and you=E2=80=99re back to 25Mb= ps on needed bandwidth to support multiple concurrent activities.

While I concede there is not a widely accepted standard for evaluating=20 video quality (at least not one of which I=E2=80=99m aware), I dislike that= Y=20 axis (Quality) on their graphs has no metric, especially without a=20 definition for how they define quality =E2=80=93 is it based on lost data, = % of=20 pixels expressing compression artifacts, pixel color drift, or something else they created for the purpose of making their case? I would say=20 that NONE of the photos shown constitute a good or excellent quality=20 level, where all show significant compression artifacts at the=20 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=20 objects =E2=80=93 the kinds of frames and scenes that compress extremely we= ll.=20 Again, this is why we must look to the market to determine what it=20 needs, not individual proposals.

The article also acknowledges that the graph points represent the=20 average, meaning some frames are better and some are worse. This is bad=20 because with any lossy compression system, there is a (subjective) =E2=80= =9Cgood enough=E2=80=9D level, where values above that don=E2=80=99t add much, but= frames that=20 are worse will stand out as bad. You can=E2=80=99t just watch the average = =E2=80=93=20 you=E2=80=99re forced to also watch the bad frames. In real-world usage, th= ese=20 will be the frames during high-speed image changes =E2=80=93 explosions in= =20 action movies or a fast-panning scene), often the times when preserving=20 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=20 X-wing fighters as the dogfight leads to explosions around them).

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

Now, to be fair, I have no doubt that there exist today and will exist=20 even more so in the future superior compression that could lower the=20 bitrate needed at any given resolution and quality level. The one=20 described in the article could be an important step in that direction.=20 No doubt Netflix already has multiple economic incentives to reduce=20 required bandwidth =E2=80=93 their own bandwidth costs, which are a substan= tial % of their total operating costs, access to customers who can=E2=80=99t get= =20 25Mbps connections, competition from other streaming services if they=20 can claim that their streams are less affected by what others in the=20 house are doing or are higher quality at any given bandwidth, etc. As=20 noted above, however, that is all moot unless all of the major streamers adopt comparable bandwidth reduction technologies and ALSO that all=20 major existing home equipment can support it today (i.e., without=20 requiring people replace their TV=E2=80=99s or STB=E2=80=99s). Absent that,= it=E2=80=99s just a=20 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=20 REQUIRE users to have 25Mbps connections in order to offer the 4K HDR=20 streams. Yes, users can lie and may find they can watch most of the 4K=20 content they wish with only 20Mbps or in some cases 15Mbps connections,=20 but that=E2=80=99s clearly not a reason why an ISP should say, =E2=80=9CWe = don=E2=80=99t need to offer 25Mbps for our customers to be able to access any major streaming service.=E2=80=9D

Cheers,
Colin
--000000000000460d4e0617caeb46--