8 ms·

Replacing HLS/Dash – Live Mass Fanout with Media over QUIC

150 points by kixelated 3y ago

repelsteeltje 3y ago
Hmm. Okay that's nice and all. But isn't client-side adaptive bitrate switching the point of HLS and DASH? Given that server side software (encoders, live and VOD origins) and clients (shaka, hls.js, dash reference client, set top boxes, smart TVs) exist ... doesn't it make more sense to set up http/3 and have it all in a well established standard?
- pipo234 3y ago
  Looks like a Will Law (of DASH fame) pet project. Interesting to see where it will lead. Seems to have sponsorship from some industry heavyweights Meta, Cisco, Twitch, Google, Akamai, Ericson. But notable absentee is of course: Apple (!) https://datatracker.ietf.org/doc/draft-ietf-moq-transport/ https://datatracker.ietf.org/doc/draft-ietf-moq-transport/
  - goeiedaggoeie 3y ago
    Delivery on web IOS specifically is the PITA. This post however uses CMAF and with IOS offering better API's for video from the next release there is a bit of hope that this protocol could be implemented without Apple needing to do it, once private relay on ios supports http3, all the bits needed to do this should be there.
    - englishm 3y ago
      The main thing we're waiting on is WebTransport in Safari. Apple has committed to adding it, and there's already been some work on it in WebKit, but we don't know when it will make its way into a Safari release yet.
      - londons_explore 3y ago
        Apple accepts external PR's for Webkit right? Couldn't someone external implement it?
        withinboredom 3y ago
        At the risk of them rejecting it and wasting everyone's time?
- kixelated 3y ago
  ABR is absolutely required for distribution. MoQ also supports ABR, but additionally gives you the ability to also drop the tail of a GoP if a rendition switch is too slow, or no lower rendition exists. As for maintaining existing standards, it depends on your goals. If you're not trying to push boundaries then absolutely, HLS/DASH is great for quickly getting off the ground. But if you're looking for something in-between HLS and WebRTC then MoQ is compelling.
- KaiserPro 3y ago
  But as the article points out HTTP/3 is designed to be reliable. This is why TCP is not really great for realtime/low latency video. Re-transmission of old frames is the opposite what you want for live streaming. If you can't re-generate the frame from forward error correction, then you're shit out of luck. if you're hitting network throughput limits, wasting data on transmitting frames you cant display is not a good use of a limited resource.
adriancr 3y ago
I've always wondered why the need for ABR... Article mentions droppping from 1080p to 360p like it's a feature, but I would say its horrible to do that... If I'm watching a movie or listening to music I don't want random switches to poor quality or lower resolution and associated glitches. I'd much rather see the spinning wheel and complain to my provider that I'm not getting what I paid for or check what's going wrong. I can understand various resolutions and codecs based on user preferences and devices but that's a fixed choice. Am I in the minority here?
- izacus 3y ago
  Yes, absolutely. Vastly. Hugely. As someone who's worked in video delivery, I can't overstate how much the majority prefers not to have stutters in their video while sitting on a subway/bus/train/massive SUV.
  - JoshTriplett 3y ago
    Exactly. I'd much rather wait a minute and buffer more video at reasonable resolution and bitrate, rather than switching to something unwatchable.
    - stilldavid 3y ago
      I believe this post covers the most common use case of Twitch, which is live streaming. You don't want to be a minute behind the video when chat is live.
      - eska 3y ago
        I’m not sure, since most people don’t interact with chat. Personally I use yt-dlp with mpv and have the buffer set very large. This allows me to pause the stream when I take a toilet break or similar. When I come back I can also skip ahead through ads or idle times on the stream, or watch at increased speed to catch up if needed.
    - remram 3y ago
tschellenbach 3y ago
Replacing LLHLS and Webrtc will be hard since they both work quite well.
- belthesar 3y ago
  With regards to live video broadcasting (as opposed to VoIP), I'd be hard pressed to call WebRTC a technology that works well. WebRTC for one-to-many feeds is poor for live video for many reasons. For ABR scenarios, there's no concept of having multiple renditions, so if one subscriber is having trouble receiving video from a publisher, the subscriber reduces the bitrate of that publishers feed for all receivers (unless you take out that capability in its entirety, see the FTL protocol created by the team at Mixer). In addition to this, WebRTC has no real concept of segments, which makes building a CDN to reduce load and latency at an endpoint is a difficult proposition at best. LLHLS is darn good, but it's not as good as WebRTC-powered technologies have shown from a latency perspective. Whether that's required for particular use cases is really pertinent to the case. For non-interactive feeds, it's not really a value add. That said, the biggest quality improvements MoQ has are how it recovers from a poor connection issue, which happens frequently even on the best of consumer networks and Internet connections, let alone on poorer quality WiFi and cellular networks.
  - Sean-Der 3y ago
    WebRTC does have the concept of ABR/renditions, it is know as Simulcast [0] Agree on no segments. WebRTC CDNs are built differently because of this. Your infrastructure looks like a tree, the nodes at the edges are what viewers connect too. One design is [1], but you can have others. [0] https://blog.livekit.io/an-introduction-to-webrtc-simulcast-6c5f1f6402eb/ https://blog.livekit.io/an-introduction-to-webrtc-simulcast-... [1] https://blog.livekit.io/scaling-webrtc-with-distributed-mesh/ https://blog.livekit.io/scaling-webrtc-with-distributed-mesh...
superkuh 3y ago
Ah yes, QUIC, the protocol that is infeasible to use to connect to people you don't know without getting continued approval from a corporate CA. Imagine if you couldn't use TCP without getting re-approved by a third party corporation every ~90 days. I suppose that's fine for corporate for-profit use but it makes things extremely brittle in both the technical and social senses.
- conradludgate 3y ago
  Can you elaborate on this? This doesn't seem like a fundamental issue with QUIC
  - johncolanduoni 3y ago
    They’re probably referring to the fact that QUIC always performs TLS1.3 negotiation as part of its transport handshake, there’s simply no unencrypted version of it. However WebTransport actually supports providing a certificate hash at connection time on the client and ignoring the normal Web PKI altogether. But I doubt that will stop anyone who instinctively hates it because it came out of Google from continuing to do so.
    - conradludgate 3y ago
      Ah, I see. Well I use self signed TLS certificates just fine with QUIC. I also wouldn't log into a livestream without using a CA trusted TLS connection (unless you're ok on a free anonymous account with adverts I guess).
- thedaly 3y ago
  > the protocol that is infeasible to use to connect to people you don't know without getting continued approval from a corporate CA. What do you mean? Are you saying you can't serve content via QUIC with a certificate issued by lets say letsencrypt certbot?
  - giantrobot 3y ago
peaBerberian 3y ago
I liked this article very much (and I do share many points it's making). However there are some claims in that article that bothered me: > if you’re watching 1080p video and your network takes a dump, well you still need to download seconds of unsustainable 1080p video before you can switch down to a reasonable 360p. A client can theoretically detect a bandwidth fall (or even guess it) while loading a segment, abort its request (which may close the TCP socket, event that then may be processed server-side, or not), and directly switch to a 360p segment instead (or even a lower quality). In any case, you don't "need to" wait for a request to finish before starting another. > For live media, you want to prioritize new media over old media in order to skip old content From this, I'm under the impression that this article only represents the point of view of applications where latency is the most important aspect by far, like twitch I suppose, but I found that this is not a generality for companies relying on live media. Though I guess the tl;dr properly recognizes that, but I still want to make my point as I found that sentence not precize enough. On my side and the majority of cases I've professionally seen, latency may be an important aspect for some specific contents (mainly sports - just for the "neighbor shouting before you" effect - and some very specific events), but in the great majority of cases there were much more important features for live contents: timeshifting (e.g. being able to seek back to the beginning of the program or the one before it, even if you "zapped" to it after), ad-switching (basically in-stream targeted ads), different encryption keys depending on the quality, type of media AND on the program in question, different tracks, codecs and qualities also depending on the program, and surely many other things I'm forgetting... All of those are in my case much more important aspects of live contents than seeing broadcasted content a few seconds sooner. Not to say that a new way of broadcasting live contents with much less latency wouldn't be appreciated there, but to me, that part of the article complained about DASH/HLS by just considering the ""simpler"" (I mean in terms of features, not in terms of complexity) live streaming cases where they are used. > You also want to prioritize audio over video Likewise, in the case I encountered, we do largely prefer re-buffering over not having video for even less than a second, even for contents where latency is important (e.g. football games), but I understand that twitch may not have the same need and would prefer a more direct interaction (like other more socially-oriented media apps). > LL-DASH can be configured down to +0ms added latency, delivering frame-by-frame with chunked-transfer. However it absolutely wrecks client-side ABR algorithms. For live contents where low-latency is important, I do agree that it's the main pain point I've seen. But perhaps another solution here may be to update DASH/HLS or exploit some of its features in some ways to reduce that issue. As you wrote about giving more control to the server, both standards do not seem totally against making the server-side more in-control in some specific cases, especially lately with features like content-steering. --- Though this is just me being grumpy over unimportant bits, we're on HN after all! In reality it does seem very interesting and I thank you for sharing, I'll probably dive a little more into it, be humbled, and then be grumpy about something else I think I know :p
inthewings 3y ago
Anything that deprecates HLS which is a piece of randomly specified and implemented crap is welcome
HumblyTossed 3y ago
> It’s a bold claim I know. But I struggle to think of a single reason why you would use TCP over QUIC going forward. I know that I'm talking about apples vs oranges, but how long have we been waiting for IPv6 to take over from IPv4? I don't see QUIC taking over from TCP any time soon.
- themerone 3y ago
  Corporate firewalls are going to allow QUIC sometime between never and the heat death of the universe.
- kixelated 3y ago
  QUIC is a major functionality improvement, while IPv6 is a capacity improvement. You can do some extremely cool things with QUIC that definitely deserves a post of its own.
- JimDabell 3y ago
  > I don't see QUIC taking over from TCP any time soon. HTTP/3 uses QUIC, so there’s already a substantial amount of production traffic going over it. https://blog.cloudflare.com/http3-usage-one-year-on/ https://blog.cloudflare.com/http3-usage-one-year-on/
- cryptonector 3y ago
  Switching over all uses of TCP to QUIC will go even slower than the IPv6 migration. TCP works for most things and is trivial to use so it will continue to get use. But unlike IPv6 there's few barriers to adoption of QUIC where it really pays, so I expect that QUIC will be adopted by a lot of applications pretty quickly.
deleted 3y ago
[deleted]
favorited 3y ago
> allowed the Apple-controlled HLS player to reduce the bitrate rather than pummel a poor megacorp’s cellular network lol the telcos will just throttle you, they don't care that your twitch stream constantly pauses to buffer. lower bitrate streams make the content playable, period.
- deleted 3y ago
  [deleted]
- kixelated 3y ago
  AT&T customers will complain if AT&T throttles a RTMP stream, as it will cause indefinitely buffering. AT&T customers are less likely to complain if AT&T throttles a HLS broadcast, as the quality will just be lower.
lxgr 3y ago
> If your app delivers video over cellular networks, and the video exceeds either 10 minutes duration or 5 MB of data in a five minute period, you are required to use HTTP Live Streaming. Wait, what? Is MPEG-DASH really prohibited by Apple for native applications? Or do they just mean "HLS or equivalent; don't do progressive downloads"? What about applications that can't pick their delivery format, like web cams? Does this only apply to VOD-like use cases?
- banana_giraffe 3y ago
  They mean HLS When/If they notice you're not using HLS instead of some other solution like MPEG-DASH, they will raise a stink and force you to fix it. I know this because I had the privilege of changing a video playback stack to be 100% HLS over a weekend for a fairly big name app when it became a Pri 0 issue thanks to Apple noticing the app hadn't been using HLS 100% of the time during a minor update. There's also verbiage requiring a laughably low bitrate stream as a fallback. Our users would file bugs when we fell back to that stream instead of audio only since we had a rich audio only mode they preferred given that the video at whatever bitrate (192kbps?) for our content was nothing but a colorly mess. This was years ago, the rules are still in the app store, but I have no idea how well they're enforced anymore.
- deleted 3y ago
  [deleted]
remram 3y ago
Are the links on this page rendered exactly the same as other bold text? Why would you do this?
- jolmg 3y ago
  The links don't appear bold to me, using firefox on desktop.
- re 3y ago
  On my browser there's a barely discernible difference. The body text has a font-weight of 400; links, 500; and <strong> text, 600 (which is less than the HTML default of 700).
- kixelated 3y ago
  I am bad at web design.
  - remram 3y ago
    FYI this is what it looks like on mobile: https://remram.fr/screenshot20231115101257.png https://remram.fr/screenshot20231115101257.png
fostware 3y ago
"the shoddy cellular networks in Brazil or India or Australia." Ouch! (and yeah, ok)
- kixelated 3y ago
  Fun fact, at one point it was better (and cheaper) to serve Telstra viewers out of LA instead of our Sydney datacenter because of the mess that is Australia internet infrastructure.

150 points by kixelated 3y ago

Hmm. Okay that's nice and all. But isn't client-side adaptive bitrate switching the point of HLS and DASH? Given that server side software (encoders, live and VOD origins) and clients (shaka, hls.js, dash reference client, set top boxes, smart TVs) exist ... doesn't it make more sense to set up http/3 and have it all in a well established standard?

pipo234 3y ago
Looks like a Will Law (of DASH fame) pet project. Interesting to see where it will lead. Seems to have sponsorship from some industry heavyweights Meta, Cisco, Twitch, Google, Akamai, Ericson. But notable absentee is of course: Apple (!) https://datatracker.ietf.org/doc/draft-ietf-moq-transport/ https://datatracker.ietf.org/doc/draft-ietf-moq-transport/
- goeiedaggoeie 3y ago
  Delivery on web IOS specifically is the PITA. This post however uses CMAF and with IOS offering better API's for video from the next release there is a bit of hope that this protocol could be implemented without Apple needing to do it, once private relay on ios supports http3, all the bits needed to do this should be there.
  - englishm 3y ago
    The main thing we're waiting on is WebTransport in Safari. Apple has committed to adding it, and there's already been some work on it in WebKit, but we don't know when it will make its way into a Safari release yet.
    - londons_explore 3y ago
      Apple accepts external PR's for Webkit right? Couldn't someone external implement it?
      - withinboredom 3y ago
        At the risk of them rejecting it and wasting everyone's time?
kixelated 3y ago
ABR is absolutely required for distribution. MoQ also supports ABR, but additionally gives you the ability to also drop the tail of a GoP if a rendition switch is too slow, or no lower rendition exists. As for maintaining existing standards, it depends on your goals. If you're not trying to push boundaries then absolutely, HLS/DASH is great for quickly getting off the ground. But if you're looking for something in-between HLS and WebRTC then MoQ is compelling.
KaiserPro 3y ago
But as the article points out HTTP/3 is designed to be reliable. This is why TCP is not really great for realtime/low latency video. Re-transmission of old frames is the opposite what you want for live streaming. If you can't re-generate the frame from forward error correction, then you're shit out of luck. if you're hitting network throughput limits, wasting data on transmitting frames you cant display is not a good use of a limited resource.

adriancr 3y ago

I've always wondered why the need for ABR... Article mentions droppping from 1080p to 360p like it's a feature, but I would say its horrible to do that... If I'm watching a movie or listening to music I don't want random switches to poor quality or lower resolution and associated glitches. I'd much rather see the spinning wheel and complain to my provider that I'm not getting what I paid for or check what's going wrong. I can understand various resolutions and codecs based on user preferences and devices but that's a fixed choice. Am I in the minority here?

izacus 3y ago
Yes, absolutely. Vastly. Hugely. As someone who's worked in video delivery, I can't overstate how much the majority prefers not to have stutters in their video while sitting on a subway/bus/train/massive SUV.
- JoshTriplett 3y ago
  Exactly. I'd much rather wait a minute and buffer more video at reasonable resolution and bitrate, rather than switching to something unwatchable.
  - stilldavid 3y ago
    I believe this post covers the most common use case of Twitch, which is live streaming. You don't want to be a minute behind the video when chat is live.
    - eska 3y ago
      I’m not sure, since most people don’t interact with chat. Personally I use yt-dlp with mpv and have the buffer set very large. This allows me to pause the stream when I take a toilet break or similar. When I come back I can also skip ahead through ads or idle times on the stream, or watch at increased speed to catch up if needed.
  - remram 3y ago

tschellenbach 3y ago

Replacing LLHLS and Webrtc will be hard since they both work quite well.

belthesar 3y ago
With regards to live video broadcasting (as opposed to VoIP), I'd be hard pressed to call WebRTC a technology that works well. WebRTC for one-to-many feeds is poor for live video for many reasons. For ABR scenarios, there's no concept of having multiple renditions, so if one subscriber is having trouble receiving video from a publisher, the subscriber reduces the bitrate of that publishers feed for all receivers (unless you take out that capability in its entirety, see the FTL protocol created by the team at Mixer). In addition to this, WebRTC has no real concept of segments, which makes building a CDN to reduce load and latency at an endpoint is a difficult proposition at best. LLHLS is darn good, but it's not as good as WebRTC-powered technologies have shown from a latency perspective. Whether that's required for particular use cases is really pertinent to the case. For non-interactive feeds, it's not really a value add. That said, the biggest quality improvements MoQ has are how it recovers from a poor connection issue, which happens frequently even on the best of consumer networks and Internet connections, let alone on poorer quality WiFi and cellular networks.
- Sean-Der 3y ago
  WebRTC does have the concept of ABR/renditions, it is know as Simulcast [0] Agree on no segments. WebRTC CDNs are built differently because of this. Your infrastructure looks like a tree, the nodes at the edges are what viewers connect too. One design is [1], but you can have others. [0] https://blog.livekit.io/an-introduction-to-webrtc-simulcast-6c5f1f6402eb/ https://blog.livekit.io/an-introduction-to-webrtc-simulcast-... [1] https://blog.livekit.io/scaling-webrtc-with-distributed-mesh/ https://blog.livekit.io/scaling-webrtc-with-distributed-mesh...

superkuh 3y ago

Ah yes, QUIC, the protocol that is infeasible to use to connect to people you don't know without getting continued approval from a corporate CA. Imagine if you couldn't use TCP without getting re-approved by a third party corporation every ~90 days. I suppose that's fine for corporate for-profit use but it makes things extremely brittle in both the technical and social senses.

conradludgate 3y ago
Can you elaborate on this? This doesn't seem like a fundamental issue with QUIC
- johncolanduoni 3y ago
  They’re probably referring to the fact that QUIC always performs TLS1.3 negotiation as part of its transport handshake, there’s simply no unencrypted version of it. However WebTransport actually supports providing a certificate hash at connection time on the client and ignoring the normal Web PKI altogether. But I doubt that will stop anyone who instinctively hates it because it came out of Google from continuing to do so.
  - conradludgate 3y ago
    Ah, I see. Well I use self signed TLS certificates just fine with QUIC. I also wouldn't log into a livestream without using a CA trusted TLS connection (unless you're ok on a free anonymous account with adverts I guess).
thedaly 3y ago
> the protocol that is infeasible to use to connect to people you don't know without getting continued approval from a corporate CA. What do you mean? Are you saying you can't serve content via QUIC with a certificate issued by lets say letsencrypt certbot?
- giantrobot 3y ago

peaBerberian 3y ago

I liked this article very much (and I do share many points it's making). However there are some claims in that article that bothered me: > if you’re watching 1080p video and your network takes a dump, well you still need to download seconds of unsustainable 1080p video before you can switch down to a reasonable 360p. A client can theoretically detect a bandwidth fall (or even guess it) while loading a segment, abort its request (which may close the TCP socket, event that then may be processed server-side, or not), and directly switch to a 360p segment instead (or even a lower quality). In any case, you don't "need to" wait for a request to finish before starting another. > For live media, you want to prioritize new media over old media in order to skip old content From this, I'm under the impression that this article only represents the point of view of applications where latency is the most important aspect by far, like twitch I suppose, but I found that this is not a generality for companies relying on live media. Though I guess the tl;dr properly recognizes that, but I still want to make my point as I found that sentence not precize enough. On my side and the majority of cases I've professionally seen, latency may be an important aspect for some specific contents (mainly sports - just for the "neighbor shouting before you" effect - and some very specific events), but in the great majority of cases there were much more important features for live contents: timeshifting (e.g. being able to seek back to the beginning of the program or the one before it, even if you "zapped" to it after), ad-switching (basically in-stream targeted ads), different encryption keys depending on the quality, type of media AND on the program in question, different tracks, codecs and qualities also depending on the program, and surely many other things I'm forgetting... All of those are in my case much more important aspects of live contents than seeing broadcasted content a few seconds sooner. Not to say that a new way of broadcasting live contents with much less latency wouldn't be appreciated there, but to me, that part of the article complained about DASH/HLS by just considering the ""simpler"" (I mean in terms of features, not in terms of complexity) live streaming cases where they are used. > You also want to prioritize audio over video Likewise, in the case I encountered, we do largely prefer re-buffering over not having video for even less than a second, even for contents where latency is important (e.g. football games), but I understand that twitch may not have the same need and would prefer a more direct interaction (like other more socially-oriented media apps). > LL-DASH can be configured down to +0ms added latency, delivering frame-by-frame with chunked-transfer. However it absolutely wrecks client-side ABR algorithms. For live contents where low-latency is important, I do agree that it's the main pain point I've seen. But perhaps another solution here may be to update DASH/HLS or exploit some of its features in some ways to reduce that issue. As you wrote about giving more control to the server, both standards do not seem totally against making the server-side more in-control in some specific cases, especially lately with features like content-steering. --- Though this is just me being grumpy over unimportant bits, we're on HN after all! In reality it does seem very interesting and I thank you for sharing, I'll probably dive a little more into it, be humbled, and then be grumpy about something else I think I know :p

inthewings 3y ago

Anything that deprecates HLS which is a piece of randomly specified and implemented crap is welcome

HumblyTossed 3y ago

> It’s a bold claim I know. But I struggle to think of a single reason why you would use TCP over QUIC going forward. I know that I'm talking about apples vs oranges, but how long have we been waiting for IPv6 to take over from IPv4? I don't see QUIC taking over from TCP any time soon.

themerone 3y ago
Corporate firewalls are going to allow QUIC sometime between never and the heat death of the universe.
kixelated 3y ago
QUIC is a major functionality improvement, while IPv6 is a capacity improvement. You can do some extremely cool things with QUIC that definitely deserves a post of its own.
JimDabell 3y ago
> I don't see QUIC taking over from TCP any time soon. HTTP/3 uses QUIC, so there’s already a substantial amount of production traffic going over it. https://blog.cloudflare.com/http3-usage-one-year-on/ https://blog.cloudflare.com/http3-usage-one-year-on/
cryptonector 3y ago
Switching over all uses of TCP to QUIC will go even slower than the IPv6 migration. TCP works for most things and is trivial to use so it will continue to get use. But unlike IPv6 there's few barriers to adoption of QUIC where it really pays, so I expect that QUIC will be adopted by a lot of applications pretty quickly.

deleted 3y ago

[deleted]

favorited 3y ago

> allowed the Apple-controlled HLS player to reduce the bitrate rather than pummel a poor megacorp’s cellular network lol the telcos will just throttle you, they don't care that your twitch stream constantly pauses to buffer. lower bitrate streams make the content playable, period.

deleted 3y ago
[deleted]
kixelated 3y ago
AT&T customers will complain if AT&T throttles a RTMP stream, as it will cause indefinitely buffering. AT&T customers are less likely to complain if AT&T throttles a HLS broadcast, as the quality will just be lower.

lxgr 3y ago

> If your app delivers video over cellular networks, and the video exceeds either 10 minutes duration or 5 MB of data in a five minute period, you are required to use HTTP Live Streaming. Wait, what? Is MPEG-DASH really prohibited by Apple for native applications? Or do they just mean "HLS or equivalent; don't do progressive downloads"? What about applications that can't pick their delivery format, like web cams? Does this only apply to VOD-like use cases?

banana_giraffe 3y ago
They mean HLS When/If they notice you're not using HLS instead of some other solution like MPEG-DASH, they will raise a stink and force you to fix it. I know this because I had the privilege of changing a video playback stack to be 100% HLS over a weekend for a fairly big name app when it became a Pri 0 issue thanks to Apple noticing the app hadn't been using HLS 100% of the time during a minor update. There's also verbiage requiring a laughably low bitrate stream as a fallback. Our users would file bugs when we fell back to that stream instead of audio only since we had a rich audio only mode they preferred given that the video at whatever bitrate (192kbps?) for our content was nothing but a colorly mess. This was years ago, the rules are still in the app store, but I have no idea how well they're enforced anymore.
deleted 3y ago
[deleted]

remram 3y ago

Are the links on this page rendered exactly the same as other bold text? Why would you do this?

jolmg 3y ago
The links don't appear bold to me, using firefox on desktop.
re 3y ago
On my browser there's a barely discernible difference. The body text has a font-weight of 400; links, 500; and <strong> text, 600 (which is less than the HTML default of 700).
kixelated 3y ago
I am bad at web design.
- remram 3y ago
  FYI this is what it looks like on mobile: https://remram.fr/screenshot20231115101257.png https://remram.fr/screenshot20231115101257.png

fostware 3y ago

"the shoddy cellular networks in Brazil or India or Australia." Ouch! (and yeah, ok)

kixelated 3y ago
Fun fact, at one point it was better (and cheaper) to serve Telstra viewers out of LA instead of our Sydney datacenter because of the mess that is Australia internet infrastructure.