Error MF_E_NOTACCEPTING while ingesting take from the Capture Manager

Development Asset Creation
, ,
1

Hello,

While trying to ingest a take captured on an Iphone 16 with the Capture Manager on Unreal 5.6,

We get the following error:

[2025.11.13-13.35.32:140][555]LogMetaHumanCaptureSource: Error: Cannot open the audio file //Path/Take_1_iPhone.mov: -1072873851
[2025.11.13-13.35.32:140][555]LogMetaHumanCaptureSource: Error: Cannot open the video file //Path/Take_1_iPhone.mov_1_iPhone.mov: -1072873851
[2025.11.13-13.35.32:233][555]LogMetaHumanCaptureSource: Error: Failed to import a take(1): Conversion of data for take Take_1 failed: Failed to open the video file: //Path/Take_1_iPhone.mov_1_iPhone.mov.

It seems that the error code -1072873851 corresponds to this error code defined in WmfMediaDecoder.cpp:

#define MF_E_NOTACCEPTING                _HRESULT_TYPEDEF_(0xC00D36B5L)

Which would mean that it might be a thread issue coming from the Metahuman API.

Is there anything we are missing ?

Please note that trying to import the same data from LiveLinkHub does work, but we have a heavy automated import flow that uses the in editor Capture Manager and would like to avoid switching to LiveLinkHub if possible.

Thanks in advance for your time,

Have a nice day,

Timothé Louzier

2

Hi Timothé,

Can I check if you are using the LiveLink Face Connection or LiveLink Face Archives capture source type in Capture Manager?

Mark.

3

Hello Mark,

Sure, we use LiveLink Face Archives

4

Thanks. I’m discussing this with the engineering team - it’s not an error we’ve encountered before so we are thinking about what the appropriate next troubleshooting steps would be.

5

Hi Timothé,

As you said you have an existing automated import flow using Capture Manager, I’m assuming the project predates Unreal Engine 5.6. Are you able to try ingesting the same take in a previous Unreal Engine version (such as 5.5)?

In the screenshot the file path is redacted and the log refers to //Path/Take_1_iPhone.mov_1_iPhone.mov. I’m therefore also assuming that you’ve redacted the path in the log file, is that right? Does the actual path referred to in the screenshot/log point to data that exists (and has read permissions etc)?

Do you have other, similar takes that you are able to ingest successfully, or are they all affected by this problem?

Thanks,

Mark.

6

Hello,

Yes we updated our workflow a few times starting in 5.4 and then in 5.5, I could try to ingest the recent takes we have on an older version yes, I’ll return to you when it’s done, but I trust the problem isn’t coming from the takes because we can import them fine in LiveLinkHub.

I did censor these paths just for privacy reasons while making this post, the actual paths are correct and the data is accessible, it is notable however that these are paths to our NAS, so I will try to do the same process again and copy files locally.

We are currently processing 5 batches of takes recorded on different days on the same equipment. It’s about 150 recordings, and so far all of them were succesfully ingested with LiveLinkHub.

I only tried 5 or 6 different recordings from different batches on the in editor capture manager but they all had this same problem.

I’ll return to you again after more tests, but I hope these precisions helped you so far.

Thank you,

Timothé

7

> but I trust the problem isn’t coming from the takes because we can import them fine in LiveLinkHub.

Yes, I would tend to agree. As the error message is unfamiliar from our own testing (and we’ve not been able to replicate this when ingesting our own iPhone 16 takes) we’re trying to narrow down what might be the cause with a few different troubleshooting steps.

And yes, with that in mind, testing a network vs. local path would also be helpful, thank you.

Mark.