#No accelerated colorspace conversion found from yuv420p to bgra.

12 messages · Page 1 of 1 (latest)

vital ruin
#

Issue: GIF export is not working with 4.0.319, even though it's working with 4.0.107.

Context:
Apparently the FFmpeg logic has been updated between those versions and causing an error.
I've also upgraded the version to 4.0.332, but didn't get much luck and had the same error.
And since I'm using a new feature available in the 4.0.319, I'd like to avoid downgrading if possible.
What kind of action can I take? Thanks so much in advance 🙏

Remotion-Version: 4.0.319 (recently upgraded from 4.0.107

Expected behavior: GIF export should work.

Actual behavior: I'm seeing the attached error.

Steps to reproduce: GIF export in 4.0.107 is working as expected. It fails with 4.0.319.

📎 message.txt 📎 log-events-viewer-result.csv
vital ruin
vital ruin
#

I saw this video and tried below options but also didn't work 😢 Maybe these are just related to the transparent gif, and not related to my issue directly.

  • imageFormat: "png"
  • pixelFormat: "yuva444p10le",
YouTube
Remotion
What's new in Remotion – November 2023 - January 2024

Many new features have been introduced to Remotion from November 2023 to January 2024!

Chapters:
0:00 Introduction
0:22 Deployable Studio
1:50 makeTransform()
2:38 interpolateStyles()
3:46 fitText()
4:18 Better GIFs
5:44 New transitions
6:09 Better Props editor
6:54 Better timeline
7:41 HDR videos
8:12 Reproduction
9:01 Jump to frame
9:36 Open ...

▶ Play video
vital ruin
compact osprey
#

No accelerated colorspace conversion is just a warning which is expected

you are getting a SIGKILL which means the OS killed the remotion process because it used too many resources.

are you exporting a huge GIF by any chance? try lowering the output size with --scale and --every-nth-frame options to limit the gif size. GIF compression is very bad, so it's likely you would end up with a humongous size anyways

vital ruin
#

Yeah but the weird thing is version 4.0.137 works, but 4.0.138+ don't. For now, I've downgraded our version from 4.0.319 to 4.0.137 to fix the issue.

#

I just didn't want to lose quality or original dimensions by scaling down the result. We're already using --every-nth-frame option with value 2.

#

I'm curious why 4.0.138 breaks and 4.0.137 works, even though I tested with the exact same settings.

#

Tested export sizes were various - from around 7M to 99 MB.
It even failed with the fairly smaller sizes in 4.0.138+ versions, and they all worked under 4.0.137.

compact osprey
# vital ruin Yeah but the weird thing is version 4.0.137 works, but 4.0.138+ don't. For now, ...

the reason is that from this version on we are now correctly determining the palette.

in the previous version you had a really bad quality because it would use the same 256 colors always
from that version on it would use the 256 colors that would give you the best color accuracy, so if the video is very green, the palette leans towards green shades

we woudn't wanna remove that because then we go back to bad quality
what we do is the conventional way to do it in ffmpeg 🤔 but I guess it uses more resources

vital ruin
#

ooo I see. Yes, it uses way more resources, at least 8-9 times. Based on lambda cloudwatch logs, 4.0.137 uses 1000~2000MB, but upper versions take up the entire memory (10240MB) even with the exact same settings, and it stops process.