Project

General

Profile

Actions

Emulator Issues #9941

closed

FFV1 Full Resolution Frame Dumping on 6x Native (and up) generates empty AVI file

Added by dwighthouse over 7 years ago. Updated about 7 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:
5.0-2682

Description

Game Name?

Star Fox Adventures (GC)

Game ID? (right click the game in the game list, properties, info tab)

GSAE01

MD5 Hash? (right click the game in the game list, properties, info tab, MD5 Hash: Compute)

afb0306454b581e37a62170fdfd1de09

What's the problem? Describe what went wrong.

I was attempting to use the newly-added feature to record gameplay at the internal resolution, rather than the visually output resolution on the screen, as described:
Here: https://dolphin-emu.org/blog/2016/12/01/dolphin-progress-report-november-2016/
And Here: https://dolphin-emu.org/download/dev/0212741574548fa95593e0e9d9451feca45ab83d/

When attempting to do a Frame Dump with both "Frame Dumps Use FFV1" and "Full Resolution Frame Dumps", some resolutions generate an empty AVI file. The file appears to only contain header information, but no actual frames.

Internal Resolutions, up to and including "5x Native (3200x2640)", will record correctly to an AVI file with frame data. However, higher options "6x Native (3840x3168) for 4k", "7x Native (4480x3696)", "8x Native (5120x4224) for 5k", and the undocumented 12 option, will produce an empty AVI file, containing only header information. This does not happen when using the lossy option (whatever the default for the newer FFMPEG backend uses).

What steps will reproduce the problem?

  1. Run any game (Wii or GameCube)
  2. In Graphics Configuration, enable "Full Resolution Frame Dumps" and "Frame Dumps Use FFV1"
  3. Set the Internal Resolution to 6x or higher
  4. Dump Frames for a few seconds-worth of gameplay
  5. Stop Dumping Frames
  6. Observe that the output file 'framedump0.avi' is only about 6kb in size

Which versions of Dolphin did you test on? Does using an older version of Dolphin solve your issue? If yes, which versions of Dolphin used to work?

5.0-1444 - 7192789c1162e2deb5923151d05158f459448ab9
Latest, as of time of writing. It exhibits the issue.

5.0-1374 - 0212741574548fa95593e0e9d9451feca45ab83d
Same issue. This was the first version to have the "Full Resolution Frame Dumps".

Since both the first relevant version and the current version exhibit the issue, it is unlikely any previous versions of Dolphin did not have this issue.

What are your PC specifications? (CPU, GPU, Operating System, more)

SYSTEM
OS Name Microsoft Windows 10 Pro
Version 10.0.10240 Build 10240
System Manufacturer Gigabyte Technology Co., Ltd.
System Model Z87X-UD4H
System Type x64-based PC
Processor Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3401 Mhz, 4 Core(s), 8 Logical Processor(s)
Installed Physical Memory (RAM) 32.0 GB
Total Physical Memory 31.9 GB

GPU
Name NVIDIA GeForce GTX 760

Is there any other relevant information? (e.g. logs, screenshots,
configuration files)

It is very obvious when the issue is happening, as the game does not slow down nearly as much during the recording process at 6x and higher resolutions. It's as if the encoder gives up early.

This is not game-specific, the issue was observed with more than one game.

This issue occurred both in the Vulkan and OpenGL backends. It appears that DirectX backends do not have a "Full Resolution Frame Dumps" option.

No errors appeared in the logs for any of this.

I have attached one such empty AVI file to this issue.

(Note: The descriptions of the resolutions in the UI do not correspond to what is actually recorded. For example, the "5x Native (3200x2640)" option actually creates a video with a 4279x2640 resolution for "Force 16:9", and 3209x2640 for "Force 4:3" under the Aspect Ratio option.)


Files

framedump0.avi (5.59 KB) framedump0.avi Generated Empty AVI dwighthouse, 12/07/2016 07:36 AM
Actions #1

Updated by Fog over 7 years ago

Does this happen with non-FFV1?

Maybe I should read closer first.

Anyways, is it possible to try this on an older version of Dolphin to see if the issue occurs there as well?

Actions #2

Updated by dwighthouse over 7 years ago

Fog wrote:

Does this happen with non-FFV1?

Maybe I should read closer first.

Anyways, is it possible to try this on an older version of Dolphin to see if the issue occurs there as well?

No, the empty-file issue does not occur with FMP4, aka the Xvid default frame dump setting, as mentioned in the original post:

This does not happen when using the lossy option (whatever the default for the newer FFMPEG backend uses).

Yes, I did try it with an older version, which I mentioned in the original post. It happens in the very first version with this feature (which is only a week old):

5.0-1374 - 0212741574548fa95593e0e9d9451feca45ab83d
Same issue. This was the first version to have the "Full Resolution Frame Dumps".

Since both the first relevant version and the current version exhibit the issue, it is unlikely any previous versions of Dolphin did not have this issue.

Actions #3

Updated by Fog over 7 years ago

On initial debugging, it seems like it's triggering ffmpeg's ENOMEM error, which means not enough memory. it probably doesn't trigger for FMP4 because of the lossy nature of the codec.

I'm looking into it further.

Actions #4

Updated by dwighthouse over 7 years ago

Fog wrote:

On initial debugging, it seems like it's triggering ffmpeg's ENOMEM error, which means not enough memory. it probably doesn't trigger for FMP4 because of the lossy nature of the codec.

I'm looking into it further.

I have 32GB of memory and hundreds of gigabytes of SSD drive space. It would surprise me if that was the actual root cause. Perhaps FFMPEG has some bare-minimum expected encoding speed or memory bandwidth requirements?

Actions #5

Updated by Helios over 7 years ago

  • Status changed from New to Accepted
Actions #6

Updated by Fog over 7 years ago

So I fully debugged what was going on, and it's not an issue with running out of memory. It turns out that ffmpeg has a bug which prevents FFV1 video greater than 5K to be properly encoded.

I've created a ticket on ffmpeg's bug tracker explaining what the issue is: https://trac.ffmpeg.org/ticket/6005

Actions #7

Updated by Fog over 7 years ago

  • Status changed from Accepted to Work started

The issue has been fixed upstream in ffmpeg.

I'll be waiting for the next stable release to compile the new libraries for Windows.

Actions #8

Updated by dwighthouse over 7 years ago

Fog wrote:

The issue has been fixed upstream in ffmpeg.

I'll be waiting for the next stable release to compile the new libraries for Windows.

That was quick! Thanks for that. Looks like it could be anywhere from a day to 3 months before that change makes it into ffmpeg. I can't wait! 8K GameCube game recordings, here I come! :D

Actions #9

Updated by dwighthouse over 7 years ago

Fog wrote:

I'll be waiting for the next stable release to compile the new libraries for Windows.

There was a new FFMPEG release yesterday, but it does not appear that they have included this fix in the release. :(

Actions #10

Updated by Fog over 7 years ago

dwighthouse wrote:

Fog wrote:

I'll be waiting for the next stable release to compile the new libraries for Windows.

There was a new FFMPEG release yesterday, but it does not appear that they have included this fix in the release. :(

I can only find info on 3.2.2, was there something newer released?

Actions #11

Updated by dwighthouse over 7 years ago

Fog wrote:

I can only find info on 3.2.2, was there something newer released?

My mistake, I read "Dec. 5" as "Jan. 5". Over a month, and they still haven't done a new release. This is pretty rare, given their logs.

Actions #13

Updated by dwighthouse about 7 years ago

Fog wrote:

The issue has been fixed upstream in ffmpeg.

I'll be waiting for the next stable release to compile the new libraries for Windows.

Another reminder. The fix has been pushed upstream in ffmpeg. This issue can be addressed now, Fog. Thanks for working on this.

Actions #14

Updated by Fog about 7 years ago

Thanks, will look into compiling this now.

Actions #15

Updated by ZephyrSurfer about 7 years ago

FFmpeg was updated to 3.2.4
Is this resolved then?

5.0-2682: https://dolphin-emu.org/download/dev/30f0ebf95ef0ceb203262b2406b537a56c2fe603/

Actions #16

Updated by dwighthouse about 7 years ago

ZephyrSurfer wrote:

FFmpeg was updated to 3.2.4
Is this resolved then?

5.0-2682: https://dolphin-emu.org/download/dev/30f0ebf95ef0ceb203262b2406b537a56c2fe603/

I just did a test at the max selectable resolution using FFV1. Though I can barely preview the output, it does appear to work, capturing all the frames in the output video.

Actions #17

Updated by JosJuice about 7 years ago

  • Status changed from Work started to Fixed
  • Fixed in set to 5.0-2682
Actions

Also available in: Atom PDF