Jump to content

Return the raw AVIF image stream in the API instead of the transcoded WebP


Recommended Posts

Posted (edited)

The item local image resource information is as follows:

// http://localhost:8096/emby/Items/1234/Images?api_key={{apikey}}

[
    {
        "ImageType": "Primary",
        "Path": "C:\\Users\\name\\AppData\\Roaming\\Emby-Server\\programdata\\metadata\\library\\14\\1438932bab36b645df3b989a488596d5\\poster.jpg",
        "Filename": "poster.jpg",
        "Height": 536,
        "Width": 357,
        "Size": 0
    },
    {
        "ImageType": "Art",
        "Path": "C:\\Users\\name\\AppData\\Roaming\\Emby-Server\\programdata\\metadata\\library\\14\\1438932bab36b645df3b989a488596d5\\clearart.avif",
        "Filename": "clearart.avif",
        "Height": 1129,
        "Width": 1920,
        "Size": 0
    },
    {
        "ImageType": "Backdrop",
        "ImageIndex": 0,
        "Path": "C:\\Users\\name\\AppData\\Roaming\\Emby-Server\\programdata\\metadata\\library\\14\\1438932bab36b645df3b989a488596d5\\fanart.jpg",
        "Filename": "fanart.jpg",
        "Height": 536,
        "Width": 800,
        "Size": 0
    }
]
❯ ls

    Directory: C:\Users\name\AppData\Roaming\Emby-Server\programdata\metadata\library\14\1438932bab36b645df3b989a4885
96d5

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---          2025/10/17    22:37         414375 clearart.avif
-a---          2025/10/19     0:01         248915 fanart.jpg
-a---          2025/10/19     0:01         110337 poster.jpg

// http://localhost:8096/emby/Items/1234/Images/Art?tag=0b580ddf8112c8b78418056f2e87468b&quality=100

Request headers

GET /emby/Items/1234/Images/Art?tag=0b580ddf8112c8b78418056f2e87468b&quality=100 HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7,ja-JP;q=0.6,ja;q=0.5
Cache-Control: no-cache
Connection: keep-alive
DNT: 1
Host: localhost:8096
Pragma: no-cache
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36
sec-ch-ua: "Google Chrome";v="141", "Not?A_Brand";v="8", "Chromium";v="141"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"

Response headers

HTTP/1.1 200 OK
Content-Length: 1730744
Content-Type: image/webp
Date: Sun, 19 Oct 2025 12:58:45 GMT
Server: UPnP/1.0 DLNADOC/1.50
...

Returning the WebP stream not only results in a significantly larger file size compared to the original AVIF, but this increase is achieved through a lossy-to-lossy conversion. I would like to know if the Emby API will be able to return the original AVIF stream in the future ?

server version: 4.9.2.5-beta

Edited by syvcxm
Posted

hi, you can add format=avif to the query string to force it if you wish.

Posted
21 minutes ago, Luke said:

hi, you can add format=avif to the query string to force it if you wish.

Hi luke, Taking the itemid [1234] I listed above as an example,

// {host}/emby/Items/1234/Images/Art?tag=0b580ddf8112c8b78418056f2e87468b&format=avif

// {host}/emby/Items/1234/Images/Art?tag=0b580ddf8112c8b78418056f2e87468b&quality=100&format=avif

HTTP/1.1 200 OK
Date: Sun, 19 Oct 2025 20:08:28 GMT
Content-Type: image/avif
Content-Length: 2394206
...

 

7 hours ago, syvcxm said:
-a---          2025/10/17    22:37         414375 clearart.avif

However, the local clearart.avif file size is 414,375 bytes, while the API returns a size of 2,394,206 bytes. Moreover, the API response time is particularly long, and the server CPU usage spikes momentarily. I can confirm that the Emby server performed a format conversion on the original AVIF file and generated a new AVIF file for return. This is still a lossy-to-lossy format conversion.

Posted
20 minutes ago, Luke said:

Hi there, please attach the Emby server log from when the problem occurred:

Thanks!

 

// http://192.168.50.62:8097/emby/Items/201010/Images/Art?tag=cb7a1aa97be71be698d5f2d512891d86&format=avif

Since I initiating the request in chrome, only two new lines have been added to the logs\embyserver.txt log file:

2025-10-20 04:41:54.250 Info ImageService-0HNGECF06UDSS:00000001: http/1.0 Response 500 to ‌‍‍192.168.50.22‌. Time: 83468ms. GET http://‌‍‍192.168.50.62‌/emby/Items/201010/Images/Art?tag=cb7a1aa97be71be698d5f2d512891d86&format=avif. 
2025-10-20 04:43:15.792 Info ImageService-0HNGECF06UDST:00000001: http/1.0 Response 500 to ‌‍‍192.168.50.22‌. Time: 83719ms. GET http://‌‍‍192.168.50.62‌/emby/Items/201010/Images/Art?tag=cb7a1aa97be71be698d5f2d512891d86&format=avif. 

Changes in the Emby ProgramData directory are as follows:

---> programdata\cache: a new .avif temporary file appeared

---> several ten seconds later, the file was moved to programdata\cache\images\resized-images\7\7fdb539f-c0fb-1d7e-e10c-74df242f340f.avif

---> when I refreshed the webpage again, the browser returned an avif file matching the size of the file in the resized-images directory.

 

I have provided an AVIF file in the attachment for the reproduction process.

clearart.avif

  • Thanks 1
  • 1 month later...
Posted (edited)
On 10/20/2025 at 4:29 AM, Luke said:

Hi there, please attach the Emby server log from when the problem occurred:

Thanks!

 

Hi, luke, is there any update on this? Currently, it is not possible to retrieve the raw AVIF file stream via the API.

Artwork pic format sha1 of pic in emby appdata folder / get via api query params
.jpg match quality=100 work
.avif not match

quality=100 not work

quality=100&format=avif not work

 

Edited by syvcxm
Posted

Have you tried using the latest version?

Posted (edited)
12 minutes ago, Luke said:

Have you tried using the latest version?

Yes, i tested in latest 4.9.2.7 beta emby server, latest chrome stable version in windows 11:
For api url:

{{host}}/emby/Items/1234/Images/Art?tag=ea33722e999d14aff67aa72ea41ee251

(emby local appdata file: C:\Users\name\AppData\Roaming\Emby-Server\programdata\metadata\library\a5\a51322afc94660df04c93e5154d22e5b\clearart.avif)

it returns content-type: image/webp

when add "?quality=100&format=avif" in url, it returns image/avif much larger than emby local clearart.avif in metadata folder.

Edited by syvcxm
Posted
16 minutes ago, Luke said:

Hi there, please attach the Emby server log from when the problem occurred:

Thanks!

 

In my previous reply, I provided the AVIF file used to reproduce the issue I pointed out.

On 10/20/2025 at 5:07 AM, syvcxm said:

// http://192.168.50.62:8097/emby/Items/201010/Images/Art?tag=cb7a1aa97be71be698d5f2d512891d86&format=avif

Since I initiating the request in chrome, only two new lines have been added to the logs\embyserver.txt log file:

2025-10-20 04:41:54.250 Info ImageService-0HNGECF06UDSS:00000001: http/1.0 Response 500 to ‌‍‍192.168.50.22‌. Time: 83468ms. GET http://‌‍‍192.168.50.62‌/emby/Items/201010/Images/Art?tag=cb7a1aa97be71be698d5f2d512891d86&format=avif. 
2025-10-20 04:43:15.792 Info ImageService-0HNGECF06UDST:00000001: http/1.0 Response 500 to ‌‍‍192.168.50.22‌. Time: 83719ms. GET http://‌‍‍192.168.50.62‌/emby/Items/201010/Images/Art?tag=cb7a1aa97be71be698d5f2d512891d86&format=avif. 

Changes in the Emby ProgramData directory are as follows:

---> programdata\cache: a new .avif temporary file appeared

---> several ten seconds later, the file was moved to programdata\cache\images\resized-images\7\7fdb539f-c0fb-1d7e-e10c-74df242f340f.avif

---> when I refreshed the webpage again, the browser returned an avif file matching the size of the file in the resized-images directory.

 

I have provided an AVIF file in the attachment for the reproduction process.

clearart.avif 459.35 kB · 1 download

 

embyserver.txt

Posted

Have you tried the latest build? In my testing I am getting back the original image.

Posted (edited)
15 hours ago, Luke said:

Have you tried the latest build? In my testing I am getting back the original image.

I was able to reproduce the issue in the latest 4.9.2.7 beta version. I'm wondering if this problem is related to AV1 hardware decoding on the emby server graphics card, since my card currently doesn't support AV1 hardware acceleration.

Edited by syvcxm
Posted

Hi, no that doesn’t get taken into account.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...