had a bug report up for about a month can I get someone to take a look and acknowledge.

yeah still seem to be broken

The rundown:

[BUG] in -BENCHMARK function when used with -DUMPMOVIE
I had originally thought that this was an issue with the -DUMPMOVIE function but as it turns out I believe the bug is in the -BENCHMARK command line function. I’m not sure if it is there and broken or just an oversight. But currently it doesn’t hold the next frame from being played until -DUMPMOVIE has finished writing the frame. So while your written frames may not have gaps your are not capturing anywhere near all of the frames. Especially if you are using very highly detailed and/or -DUMP_TILED, It should hold and wait till the frame is written before advancing to the next frame

I found the dropped frame issue can be reproduced in just about any project. it works and can be tested with any project. Try to capture 1080p frames sequence using it in conjunction with -BENCHMARK and FPS=24 then set a limit of say 10 seconds. This should produce a frame sequence of 240 frames. This sequence should play back smooth as butter even though you machine is stopping to record the frame. But it wont! and you will most likely have a number less than 240. Most likely way less. What is actually happening is while the machine is writing the frame Unreal is going on continuing to play though while the frame is writing and then when the frame is finished being written the game then start writing then begins recording a new frame. The problem is since benchmark is not waiting for the frame to be finished writing before advancing to the next frame, you get gaps. Not in the numbers of the frames mind you but in the playback of the animation. This is also evident in that the number of frames will be less than the the sum of FPS*duration. The only thing needed is a check to be added to the BENCHMARK function that when it is used in conjunction with DUMPMOVIE or DUMP_TILED that it holds at the end of each frame to wait for the frame to write before advancing. If this is done then you can even use DUMP_TILE=2 a and dump an animation of 4K frames with a minimum level card and still achieve silky smooth playback. Granted the time per frame will be several seconds but as long as the BENCHMARK functions hold the advancement of the animation and waits for the frame to be written then there will be no problem you can go as big as you system will do without crashing or running out of drive space.

So what it boils down to is a write completion check built into the BENCHMARK function. From what I understand this is the way it is designed to work so it make be there and just not functioning properly.

So can someone kindly tell us how when or if this is going to be fixed or if Epic has a work around “That large world kite cinematic was nice” Please share with us how. Had I not managed to get it recorded by borrowing an expensive capture card I would have gotten fired about a month ago because if this mess.

Please share with us how you are getting around this. or Log it as a bug please and tell us how to Prod/Tack its progress.

Again never got any takers before but if someone thinks they know how to fix this I’m willing to pay and will make the fix available to all!

Hi there, terribly sorry about that! I am surprised you have not yet received any contact about your bug report. I can see there has been a technician assigned to it, so I will be talking to him to get a response to you ASAP. Thank you for your patience!


I’ve got a meeting set up with one of our Cinematics guys this week to answer questions. We’re going through Epic’s process from beginning to end.

He says that Epic does not even use this method for creating cinematics any longer. Once I have the notes and his entire process I plan on reporting back to you.

Apologies for the wait.

Thanks guys. I await the results.

Well? so how did this meeting go? whats the word? This seems to keep getting dropped.

I responded yesterday on your answerhub post.