FYI: Blenders EXR IO doesnt work well with Unreal Media Textures / IMG Media. Re-Render your EXRs with After Effects or similar to avoid frame skipping in MRQ.

This cost me my entire Saturday.

I have an EXR sequence rendered in Blender with Raw colorspace, no colorspace applied. I was using it in UE 5.3 and I had a very weird issue where Movie Render Queue where the rendered image had the media plate only refresh at 15 fps or skipping every second frame (project set to 30 fps).

I tried every setting in the book for hours, tried adjusting project settings, etc. I needed EXRs for a high dynamic range as the plate was illuminating.

What confused me is that it was not related to performance, the same exrs at 1/4 res still skipped every second frame. With PNGs or JPGs it worked fine.

In my desperation i tried re-rendering the EXRs in After Effects and it worked fine. Talking to some pros on a UE discord, it seems like EXR can contain some settings that can confuse UE. As Blender is a very popular DCC and this might also affect other EXRs, I wanted to share this with you.

Why? I have absolutely no idea. I will file a ticket with the blender devs to investigate.

Hello you encountered a strange issue with UE5.3 where EXRs rendered with Blender’s Raw color space were only refreshing at 15fps in the movie render Queue, despite your project being set to 30fps. This issue persisted even at lower resolutions, suggesting it wasn’t a performance bottleneck. Interestingly, PNGs and JPGs worked fine and re rendering the EXRs in After Effects solved the problem. This suggests MyIndigoCard that certain settings within Blender’s EXRs might be causing confusion in UE5.3. While the exact cause is unknown it is worth noting as a potential issue for other blender users working with EXRs in UE.

Can I get one of those exrs off you or even better the whole sequence? We’d like to investigate. It could be the compression Blender uses. Are these exrs uncompressed? UE could be lagging trying to uncompress them.

Apologies for the late reply! I didnt think anyone would reply here.

The Blender devs have also requested the actual EXR Sequence, so I uploaded 30 frames of both the original sequence coming out of Blender and the Re-rendered version from After Effects.

I have already tested different compression methods, and even uncompressed (huge) exrs - it is always exactly one frame skipped. Makes me think its not lag and some other weird thing.

I got a pretty beefy rig here as well, 13900K with a 4090.

Original EXR Image Sequence from Blender: Storage Share

Re-Rendered EXR Image Sequence from After Effects: Storage Share

Thanks for these. The ones from Blender are compressed with DWAA (lossy), while the ones from AE are using ZIP compression (non-lossy). We’ll start some conversations internally to see what the support options are for this compression type. Thanks for reporting it!

1 Like

Hey, just making sure to highlight this before you do huge investigations:

I had the same error no matter what compression method I chose in Blender. ZIP, DWAA and even none, which resulted in huge files, had exactly the same one frame skipped.

I think its more related to maybe some baked-in timecode? One of the Blender devs mentioned something along those lines. Quoting him directly: “The AE files also have some extra framesPerSecond and timeCode metadata, perhaps that makes a difference.”

Interesting. Yeah, I was looking at Blender export options, and it seems you can choose Zips. I’ll ask the devs about that metadata but I would be surprised if that’s whats tripping up UE.

Ok so we do extract the framerate from the first frame in FExrImgMediaReader::GetInfo so that could explain the difference. So only the AE one specifies a framerate of 30fps, whereas the blender sequence isn’t defined and would fall back to the IMG media plugin setting (unless it’s overridden in the image media source file). You could could lobby (or fix) Blender to also output framerate metadata? On our side, the fact that framerate settings comes from either overrides, metadata or plugin setting (in order) seems correct, but probably should be documented and/or displayed to the user.