Video encoding error: green artifacts.

Videos from a certain phone always get encoded this way these days. original video's screenshot in VLC and Immich's Web UI screenshots attached. I know this didn't use to happen till a few months ago, but today, the user complained that her videos were corrupted so I inspected. Is this a known issue? Couldn't find anything on GitHub.
No description
No description
20 Replies
Immich
Immich4mo ago
:wave: Hey @leaks-repaired, Thanks for reaching out to us. Please carefully read this message and follow the recommended actions. This will help us be more effective in our support effort and leave more time for building Immich :immich:. References - Container Logs: docker compose logs docs - Container Status: docker ps -a docs - Reverse Proxy: https://immich.app/docs/administration/reverse-proxy - Code Formatting https://support.discord.com/hc/en-us/articles/210298617-Markdown-Text-101-Chat-Formatting-Bold-Italic-Underline#h_01GY0DAKGXDEHE263BCAYEGFJA
Immich
Immich4mo ago
Checklist I have... 1. :ballot_box_with_check: verified I'm on the latest release(note that mobile app releases may take some time). 2. :ballot_box_with_check: read applicable release notes. 3. :ballot_box_with_check: reviewed the FAQs for known issues. 4. :ballot_box_with_check: reviewed Github for known issues. 5. :ballot_box_with_check: tried accessing Immich via local ip (without a custom reverse proxy). 6. :ballot_box_with_check: uploaded the relevant information (see below). 7. :ballot_box_with_check: tried an incognito window, disabled extensions, cleared mobile app cache, logged out and back in, different browsers, etc. as applicable (an item can be marked as "complete" by reacting with the appropriate number) Information In order to be able to effectively help you, we need you to provide clear information to show what the problem is. The exact details needed vary per case, but here is a list of things to consider: - Your docker-compose.yml and .env files. - Logs from all the containers and their status (see above). - All the troubleshooting steps you've tried so far. - Any recent changes you've made to Immich or your system. - Details about your system (both software/OS and hardware). - Details about your storage (filesystems, type of disks, output of commands like fdisk -l and df -h). - The version of the Immich server, mobile app, and other relevant pieces. - Any other information that you think might be relevant. Please paste files and logs with proper code formatting, and especially avoid blurry screenshots. Without the right information we can't work out what the problem is. Help us help you ;) If this ticket can be closed you can use the /close command, and re-open it later if needed.
GitHub
immich-app immich · Discussions
Explore the GitHub Discussions forum for immich-app immich. Discuss code, ask questions & collaborate with the developer community.
GitHub
Issues · immich-app/immich
High performance self-hosted photo and video management solution. - Issues · immich-app/immich
Mraedis
Mraedis4mo ago
Could we get your hardware info (phone/server) and transcoding settings?
leaks-repaired
leaks-repairedOP4mo ago
Phone: Samsung S20 FE 5G. Server: AMD Ryzen 5 5600G, Fedora + Docker running on a B450M motherboard ffmpeg:
"ffmpeg": {
"accel": "vaapi",
"accelDecode": false,
"acceptedAudioCodecs": [
"aac",
"mp3",
"libopus",
"pcm_s16le"
],
"acceptedContainers": [
"mov",
"ogg",
"webm"
],
"acceptedVideoCodecs": [
"h264"
],
"bframes": -1,
"cqMode": "auto",
"crf": 23,
"gopSize": 0,
"maxBitrate": "0",
"preferredHwDevice": "auto",
"preset": "slow",
"refs": 0,
"targetAudioCodec": "aac",
"targetResolution": "1080",
"targetVideoCodec": "h264",
"temporalAQ": false,
"threads": 0,
"tonemap": "hable",
"transcode": "required",
"twoPass": false
},
"ffmpeg": {
"accel": "vaapi",
"accelDecode": false,
"acceptedAudioCodecs": [
"aac",
"mp3",
"libopus",
"pcm_s16le"
],
"acceptedContainers": [
"mov",
"ogg",
"webm"
],
"acceptedVideoCodecs": [
"h264"
],
"bframes": -1,
"cqMode": "auto",
"crf": 23,
"gopSize": 0,
"maxBitrate": "0",
"preferredHwDevice": "auto",
"preset": "slow",
"refs": 0,
"targetAudioCodec": "aac",
"targetResolution": "1080",
"targetVideoCodec": "h264",
"temporalAQ": false,
"threads": 0,
"tonemap": "hable",
"transcode": "required",
"twoPass": false
},
hwaccel.yml
services:
hwaccel:
devices:
- /dev/dri:/dev/dri # If using Intel QuickSync or VAAPI
services:
hwaccel:
devices:
- /dev/dri:/dev/dri # If using Intel QuickSync or VAAPI
leaks-repaired
leaks-repairedOP4mo ago
ffprobe-json video.mp4
leaks-repaired
leaks-repairedOP4mo ago
I've narrowed it down. The problem started somewhere between 5th and 8th December, on my server. It eerily coincides with when I must have updated to this release, which introduced support for HDR videos. I just diffed the ffprobe data of videos before and after this period. The only differences are in timestamps, bitrates and creation date; codecs and parameters are exactly the same. Something changed in how Immich processes the videos.
leaks-repaired
leaks-repairedOP4mo ago
Relevant server logs from when that 'currupted' video was processed.
leaks-repaired
leaks-repairedOP4mo ago
(I might be busy this coming week. In case this is a newly reported issue, I wanted to file on Github.... would love it if someone else could confirm and open it themselves, or I'll do it next week)
sogan
sogan4mo ago
IIRC this can happen if a video is Dolby Vision and the client doesn’t support the particular DV profile of the video. Is the video with a green cast the original or the transcode? You can right click and download it to check if you’re not sure
leaks-repaired
leaks-repairedOP4mo ago
I just checked. The transcoded video is green in VLC too. The ffprobe-json output for the video is below:
leaks-repaired
leaks-repairedOP4mo ago
To be clear, these are the commands I used to create the above outputs.
# Original video (not green)
ffprobe-json immich/library/username/2025/2025-01-16/20250116_163350.mp4 | clip
# Old video, exactly same encoding as the original video.
ffprobe-json immich/library/username/2024/2024-12-04/20241204_001409.mp4 | clip
# new transcodes (after December 5th), green.
ffprobe-json immich/encoded-video/8aa974cc-3872-4b73-9ecc-64ef94ccc5f1/40/44/404476b5-a1fb-4012-b482-fcef9c7dc3e5.mp4 | clip
# Original video (not green)
ffprobe-json immich/library/username/2025/2025-01-16/20250116_163350.mp4 | clip
# Old video, exactly same encoding as the original video.
ffprobe-json immich/library/username/2024/2024-12-04/20241204_001409.mp4 | clip
# new transcodes (after December 5th), green.
ffprobe-json immich/encoded-video/8aa974cc-3872-4b73-9ecc-64ef94ccc5f1/40/44/404476b5-a1fb-4012-b482-fcef9c7dc3e5.mp4 | clip
sogan
sogan4mo ago
Nothing really sticks out as being problematic in the metadata. Hmm If you’re sure the issue started with the HDR video release, the only transcoding change in that release was #14455
Immich
Immich4mo ago
[Pull Request] fix(server): always set transcoding device, prefer renderD* (immich-app/immich#14455)
sogan
sogan4mo ago
Maybe the change means it’s now using a different interface that leads to this bug It used to always prefer the highest index card* interface
leaks-repaired
leaks-repairedOP4mo ago
Could it be that the gpu encoding is the issue? I remember when I initially configured VAAPI, immich would try using it but bail out and use the CPU instead but the logs show that the GPU was used. Any easy way for me to change this and test?
sogan
sogan4mo ago
Yes, there’s a transcoding setting to use a specific device
Mraedis
Mraedis4mo ago
If you just toggle HWA off it will always go to the CPU 😛
leaks-repaired
leaks-repairedOP4mo ago
I experimented; disabling HA solved whatever it was that was happening.
leaks-repaired
leaks-repairedOP4mo ago
ffprobe-json on the CPU encoded video:
leaks-repaired
leaks-repairedOP4mo ago
I don't see anything standing out immediately in the diffs, except the encoder name. What's the "level" field?

Did you find this page helpful?