TerribleDev/ente
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update the docs around ffmpeg on Intel macOS (#2974)

Browse Source
This commit is contained in:
Manav Rathi
2024-08-27 12:40:28 +05:30
committed by GitHub
parent 4ecc64e478 80b86189d0
commit cee429abdb
2 changed files with 13 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
docs/docs/photos/troubleshooting/thumbnails.md
View File

@@ -22,6 +22,11 @@ canvas.
## Desktop
> [!NOTE]
>
> This issue has been fixed in the latest beta releases, and the fix will be
> also out in the next release, 1.7.4.
The only known case where thumbnails might be missing on desktop is when
uploading **videos** during a Google Takeout or watched folder sync on **Intel
macOS** machines. This is because the bundled ffmpeg that we use does not work

19
web/apps/photos/src/services/upload/uploadService.ts
View File

@@ -1108,22 +1108,19 @@ const withThumbnail = async (
//
// We can only get here when we're running in our desktop app (since
// only that works with non-File uploadItems), and the thumbnail
// generation failed. The scenarios are:
// generation failed.
//
// 1. We're trying to generate an image thumbnail on Windows or on
// ARM64 Linux. This won't be possible since the bundled
// imagemagick doesn't yet support these OS/arch combinations.
//
// 2. We're trying to generate a video thumbnail on Intel macOS.
// This won't be possible since the bundled ffmpeg doesn't
// support Rosetta.
//
// 3. Some other arbitrary exception happened.
// The only know scenario is when we're trying to generate an image
// thumbnail on Windows or on ARM64 Linux, or are trying to
// generated the thumbnail for an HEIC file on Linux. This won't be
// possible since the bundled imagemagick doesn't yet support these
// OS/arch combinations.
//
// The fallback in this case involves reading the entire stream into
// memory, and passing that data across the IPC boundary in a single
// go (i.e. not in a streaming manner). This is risky for videos of
// unbounded sizes, so we can only apply this fallback for images.
// unbounded sizes, and since anyways we are not expected to come
// here for videos, soo we only apply this fallback for images.
if (fileTypeInfo.fileType == FileType.image) {
const data = await readEntireStream(fileStream.stream);