2023-11-04, 02:52 AM
Re: https://features.jellyfin.org/posts/2285...-streaming
To expand on this, it seems that a lot of data could be saved (and processes sped up) with a few small changes.
1) Have image compression be an admin set variable.
At the moment, it is hardcoded to Q96.
Thumbnails on my home page are about 115kb. Changing the jpg compression to 50 (for example), brings the file size down to 28.9kb
2) Stop sending giant thumbnails
Thumbnails on my home page are about 185w x 277h, but the image sent is 440x660.
Changing the sent width to 200 brings the image size from 115kb to to 28.5kb
This is a tiny fix that would be a huge advantage with no effort.
Together:
Doing both (Q50, Width 200) has an image size of 8.8kb
Reducing the data sent by over 13x !
For me, Q76 is good sweet spot. Having a simple variable we can set would be great.
3) Have two image quality variables - one for local, one for remote.
Set Q96-Q76 for local users, and have Q50-Q35 or whatever potato quality you want for remote users. We already detect users and change streaming quality on this, no reason not to tie this variable to it as well.
I would suggest, for default, Q96 for local, Q76 for remote. Personally, I would immediately set them to Q76/Q35.
4) Also compress Primary images for entries more
Again, currently set to Q96. I suggest applying the same quality settings for thumbnails for primary images. Setting to Q76 reduces file size by ~75%.
My HTML computed image width is 487px. Why is JF sending a 974px wide image? set it to 500px, and make a dramatic change.
5) Backdrops differently
Entry backdrops are currently set to Q80. It still looks fine at Q50. Really though, I would suggest using the two admin-set variables: local image compression and remote image compression. Apply it to everything.
And reduce the dimensions of the images to be closer to what is actually rendered in the client/browser.
To expand on this, it seems that a lot of data could be saved (and processes sped up) with a few small changes.
Quote:Example: https://[SERVER.URL]/Items/973707f5872f38dbdb95468e65bf3884/Images/Primary?fillHeight=628&fillWidth=440&quality=96&tag=17c1b7a7b164c8edb126dc1943141776
1) Have image compression be an admin set variable.
At the moment, it is hardcoded to Q96.
Thumbnails on my home page are about 115kb. Changing the jpg compression to 50 (for example), brings the file size down to 28.9kb
2) Stop sending giant thumbnails
Thumbnails on my home page are about 185w x 277h, but the image sent is 440x660.
Changing the sent width to 200 brings the image size from 115kb to to 28.5kb
This is a tiny fix that would be a huge advantage with no effort.
Together:
Doing both (Q50, Width 200) has an image size of 8.8kb
Reducing the data sent by over 13x !
For me, Q76 is good sweet spot. Having a simple variable we can set would be great.
3) Have two image quality variables - one for local, one for remote.
Set Q96-Q76 for local users, and have Q50-Q35 or whatever potato quality you want for remote users. We already detect users and change streaming quality on this, no reason not to tie this variable to it as well.
I would suggest, for default, Q96 for local, Q76 for remote. Personally, I would immediately set them to Q76/Q35.
4) Also compress Primary images for entries more
Quote:https://[SERVER.URL]/Items/973707f5872f38dbdb95468e65bf3884/Images/Primary?fillHeight=1388&fillWidth=974&quality=96&tag=17c1b7a7b164c8edb126dc1943141776
Again, currently set to Q96. I suggest applying the same quality settings for thumbnails for primary images. Setting to Q76 reduces file size by ~75%.
My HTML computed image width is 487px. Why is JF sending a 974px wide image? set it to 500px, and make a dramatic change.
5) Backdrops differently
Entry backdrops are currently set to Q80. It still looks fine at Q50. Really though, I would suggest using the two admin-set variables: local image compression and remote image compression. Apply it to everything.
And reduce the dimensions of the images to be closer to what is actually rendered in the client/browser.