this post was submitted on 20 May 2024
45 points (95.9% liked)

Selfhosted

40347 readers
328 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
top 17 comments
sorted by: hot top controversial new old
[–] themachine@lemmy.world 52 points 6 months ago

Just look at the bit rate of what you are streaming and multiply it by 3 then add a little extra for overhead.

[–] WFloyd@lemmy.world 6 points 6 months ago

I have 35mbps upload from the ISP, and limit each stream to 8mbps. This covers direct streaming all my 1080p content and a 4K transcode as needed.

[–] Faceman2K23@discuss.tchncs.de 5 points 6 months ago

Are you transcoding?

4mbit per client for 1080 is generally a workable minimum for the average casual watcher if you have H265 compatible clients (and a decent encoder, like a modern intel CPU for example), 6 - 8mbit per client if its H264 only.

Remember that the bitrate to quality curve for live transcoding isn't as good as a slow, non-real-time encode done the brute force way on a CPU. so if you have a few videos that look great at 4mbit, dont assume your own transcodes will look quite that nice, you're using a GPU to get it done as quickly as possible, with acceptable quality, not as slowly and carefully as possible for the best compression.

[–] SigHunter@lemmy.kde.social 5 points 6 months ago

My family is very satisfied with 6 mbit/s per stream. Some HEVC, most H264. They see it as high quality. 3 Streams would be 18 to 20 Mbit/s

[–] possiblylinux127@lemmy.zip 2 points 6 months ago

How expensive is internet? If its cheap go overkill and don't worry about it.

[–] Diabolo96@lemmy.dbzer0.com 0 points 6 months ago* (last edited 6 months ago) (2 children)

I don't have a jellyfin server but 1MB/s (8mbps) for each person watching 1080p (3.6Gb per hour of content for each file) seems reasonable. ~3MB/s (24mbps) upload and as much download should work.

[–] GenderNeutralBro@lemmy.sdf.org 14 points 6 months ago (1 children)

1mbps is awfully low for 1080. Or did you mean megabyte rather than megabit?

[–] Diabolo96@lemmy.dbzer0.com 4 points 6 months ago* (last edited 6 months ago) (1 children)

I had a hunch that writing the actual Upload/download speed tather than mbps was probably wrong. My bad, my internet provider lingo is rusted.

[–] GenderNeutralBro@lemmy.sdf.org 3 points 6 months ago

Gotcha. Typically lowercase b=bit and uppercase B=Byte, but it's hard to tell what people mean sometimes, especially in casual posts.

Come to think of it, I messed up the capitalization too. Should be a capital M for mega.

[–] dysprosium@lemmy.dbzer0.com 2 points 6 months ago (2 children)

Why don't people use Mb/s and MB/s which makes it so much clearer what you're talking about

[–] SigHunter@lemmy.kde.social 7 points 6 months ago* (last edited 6 months ago) (2 children)

Back in the day, the rule was mbit (megabit) for data in transfer (network speed) and MB (megabyte) for data at rest, like on HDDs

[–] Moneo@lemmy.world 1 points 6 months ago (3 children)
[–] realbadat@programming.dev 2 points 6 months ago

Bigger number sounds better for the ISP.

[–] bitwaba@lemmy.world 1 points 6 months ago

The real answer?

Data is transmitted in packets. Each packet has a packet header, and a packet payload. The total data transmitted is the header + payload.

If you're transmitting smaller packet sizes, it means your header is a larger percentage of the total packet size.

Measuring in megabits is the ISP telling you "look, your connection is good for X amount of data. How you choose to use that data is up to you. If you want more of it going to your packet headers instead of your payload, fine." A bit is a bit is a bit to your ISP.

[–] rhys@mastodon.rhys.wtf 1 points 6 months ago

@Moneo @SigHunter Networking came to be when there were lots of different implementations of a 'byte'. The PDP-10 was prevalent at the time the internet was being developed for example, which supported variable byte lengths of up to 36-bits per byte.

Network protocols had to support every device regardless of its byte size, so protocol specifications settled on bits as the lowest common unit size, while referring to 8-bit fields as 'octets' before 8-bit became the de facto standard byte length.

[–] dysprosium@lemmy.dbzer0.com 1 points 6 months ago* (last edited 6 months ago)

So mbit/s instead of Mbit/s ? But the M in Mega is always capitalized though, except the k in kilo.

[–] lud@lemm.ee 3 points 6 months ago

The best format imo is MB/s and Mbit/s

It avoids all confusion.