From: "David Fernández" <davidfdzp@gmail.com>
To: starlink <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] It's the Latency, FCC
Date: Fri, 3 May 2024 11:09:25 +0200 [thread overview]
Message-ID: <CAC=tZ0qbxQX45j9GtZz2EnoY3uhLyOr9xgU7geShvM-_2m=ULA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 4255 bytes --]
Recent video codecs are very efficient denoisers, removing film grain from
old movies, so they don't look like the originals when decoded (and
disappointing some people).
There are ideas for solving this going on, like characterizing the film
grain with a model with some parameters. Then, the model and its
parameters, not the actual pixels with the noise, are transmitted and
generated at the decoder. with a processing that will make them ressemble
the originals (without being exactly the originals).
That is somehow a kind of semantic communication, in which instead of the
actual information, you transmit the meaningful information, not the pixels
at bit resolution. I see it a bit like using vector graphics instead of
pixels for images (SVG vs. PNG), to be able to generate images of arbitrary
resolution from the meaningful info. This is a way of breaking Shanon
capacity limits.
----------------------------------------------------------------------
Date: Fri, 3 May 2024 13:48:37 +1200
From: Ulrich Speidel <u.speidel@auckland.ac.nz>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] It’s the Latency, FCC
Message-ID: <77d8f31e-860b-478e-8f93-30cb6e0730ac@auckland.ac.nz>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
There's also the not-so-minor issue of video compression, which
generally has the effect of removing largely imperceptible detail from
your video frames so your high-res video will fit through the pipeline
you've got to squeeze it through.
But this is a bit of a snag in its own right, as I found out about two
decades ago when I was still amazed at the fact that you could use the
parsing algorithms underpinning universal data compression to get an
estimate of how much information a digital object (say, a CCD image
frame) contained. So I set about with two Japanese colleagues to look at
the reference image sequences that pretty much everyone used to
benchmark their video compressors against. One of the surprising finds
was that the odd-numbered frames in the sequences had a distinctly
different amount of information in them than the even-numbered ones, yet
you couldn't tell from looking at the frames.
We more or less came to the conclusion that the camera that had been
used to record the world's most commonly used reference video sequences
had added a small amount of random noise to every second image. - the
effect (and estimated information content) dropped noticeably when we
progressively dropped the least significant bits in the pixels. We
published this:
KAWAHARADA, K., OHZEKI, K., SPEIDEL, U. 'Information and Entropy
Measurements on Video Sequences', 5th International Conference on
Information, Communications and Signal Processing (ICICS2005), Bangkok,
6-9 December 2005, p.1150-1154, DOI 10.1109/ICICS.2005.1689234
Did the world take notice? Of course not. But it still amuses me no end
that some people spent entire careers trying to optimise the compression
of these image sequences - and all that because of an obscure hardware
flaw that the cameras which their algorithms ended up on may not have
even suffered from.
Which brings me back to the question of how important bandwidth is. The
answer is: probably more important in the future. We're currently
relying mostly on CDNs for video delivery, but I can't fail but notice
the progress that's being made by AI-based video generation. Four or
five years ago, Gen-AI could barely compose a credible image. A couple
of years ago, it could do video sequences of a few seconds. Now we're up
to videos in the minutes.
If that development is sustained, you'll be able to tell your personal
electronic assistant / spy to dream up a personalised movie, say an
operatic sci-fi Western with car chases on the Titanic floating in
space, and it'll have it generated in no time starring the actors you
like. ETA: Around 2030 maybe?
But these things will be (a) data-heavy and (b) aren't well suited for
CDN delivery because you may be the only one to every see a particular
movie, so you'll either need to move the movie generation to the edge,
or you need to build bigger pipes across the world. I'm not sure how
feasible either option is.
[-- Attachment #2: Type: text/html, Size: 4957 bytes --]
next reply other threads:[~2024-05-03 9:10 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-03 9:09 David Fernández [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-05-06 15:42 [Starlink] It’s " David Fernández
2024-05-06 13:21 David Fernández
[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
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-01 16:35 [Starlink] It's " 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='CAC=tZ0qbxQX45j9GtZz2EnoY3uhLyOr9xgU7geShvM-_2m=ULA@mail.gmail.com' \
--to=davidfdzp@gmail.com \
--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