[BUG] Transcodes fail for 4k videos captured on Android with `Store Videos Efficiently` setting enabled

[mertalev]

The bug

The Store Videos Efficiently feature was introduced in Android 12 and is enabled by default on Google Pixel phones. In this setting, videos are stored as HEVC instead of H.264 and have an additional MetaHandle stream. ffprobe struggles to interpret these videos and fails with a moov atom not found error, particularly on 4K videos.

However, it is still possible for it to successfully transcode if the video is uploaded right after recording. In this case it does not raise an error, only warning Unsupported codec with id 0 for input stream 0 (referring to MetaHandle), and ffmpeg is able to transcode the video successfully.

Possible resolutions:

• Use the Compatible Media Transcoding API. Apps that request this setting can have HEVC videos transcoded to H.264 on the phone itself.
  • However, there is a default video length limit of 1 minute. This can be overridden, but it suggests that it may be a suboptimal solution for longer videos.
• Diagnose this error further and find a way to reliably transcode these videos in the server.

• Have users disable this setting. Note that even when disabled, videos already recorded will still be stored as HEVC.

The OS that Immich Server is running on

Version of Immich Server

v1.63.2

Version of Immich Mobile App

v1.63.0

Platform with the issue

• [X] Server
• [ ] Web
• [X] Mobile

Your docker-compose.yml content

-

Your .env content

-

Reproduction steps

1. Enable `Store Videos Efficiently` on an Android phone running Android 12 or above.
2. Enable transcoding with the target video codec set to `h264` and resolution set to `1080p`.
3. Record a 4K video.
4. (optional) Wait for some time; behavior may differ between videos uploaded immediately and those that have existed for a period of time.
5. Upload it to the server.
6. Check the logs of `immich_microservices` to see whether transcoding succeeded.

Additional information

There are similar issues posted online concerning ffmpeg's handling of these videos, including here, here and here.