Playback and seek on high 240fps

Started by klusht, March 29, 2020, 01:09:04 AM

Previous topic - Next topic

klusht

Hi,

I am recording high fps gaming videos using for review and analysis (like Quake and Doom, I also have a 240Hz monitor).
Unfortunately I am not able to edit or seek frame by frame such movies.
Using 120fps is currently the only reliable option but I would like to reach 240fps.

I can load the clip but it only plays a second and then just stops the playback and only audio is moving forward. 
Is there anything I can do in settings to improve this ?

Also as I am editing frame by frame with a wheel controller and the maximum image buffer for backwards seeking is 16 frames.
Can I increase this buffer size pleeease  ? or can I make it trigger the process of rebuilding the next 16 frames back, faster ???

Regards,

eumagga0x2a

Quote from: klusht on March 29, 2020, 01:09:04 AM
Unfortunately I am not able to edit or seek frame by frame such movies.
Using 120fps is currently the only reliable option but I would like to reach 240fps.

Frame by frame seek (left and right arrow keys) should not be affected in any way by the frame rate of the video. Real-time playback is a completely different story as high fps can quickly saturate the pipeline at now ubiquitous high video resolutions like 1080p.

QuoteI can load the clip but it only plays a second and then just stops the playback and only audio is moving forward. 
Is there anything I can do in settings to improve this ?

What codec do you use in your videos?

In general, you should always use all hw acceleration features available in Avidemux for your platform (which you don't mention with a word). On Windows, this means that "DXVA2" video output must be used. "DXVA2" hw accelerated video decoding should help a lot, but only for codecs supported by hardware and Avidemux.

Please be aware that different from hw acceleration interfaces available on Linux, "DXVA2" in Avidemux is always indirect, i.e. Avidemux downloads decoded pictures from the hw decoder in the graphics card and immediately re-uploads it to the graphics card for display.

QuoteAlso as I am editing frame by frame with a wheel controller

Is it an input device to send keypresses? (The jog shuttle in Avidemux seeks to keyframes only)

Quoteand the maximum image buffer for backwards seeking is 16 frames.

Yes, likely the upper limit, actually already totally crazy, especially when using hardware acceleration as this image cache is per reference video. If a user loads a video and then appends another one, we need already 32 buffers and so on.

QuoteCan I increase this buffer size pleeease  ?

Compile Avidemux from source with a different EDITOR_CACHE_MAX_SIZE.

Quoteor can I make it trigger the process of rebuilding the next 16 frames back, faster ???

If you use H.264 or HEVC (in case your graphics card supports hw accelerated HEVC decoding), enable hw accelerated decoding in Avidemux. When creating future source videos, you should strongly reduce GOP size for H.264 or HEVC or switch to a keyframe-only codec like MJPEG if storage is plentifully available.

klusht

Hi eumagga0x2a

QuoteReal-time playback is a completely different story as high fps can quickly saturate the pipeline at now ubiquitous high video resolutions like 1080p.

That is the resolution of my recording. I did not spend too much time on testing them as I felt it is not supported.
Few tests showed that indeed is working fine, although I believe that my video sample is creating some challenges as it does play in the second half of the video.
I have attached the sample video if anyone is interested: (3GB)   https://drive.google.com/open?id=1a0UMR8fz1kojaD7FkLxUEFZZLbDNhK6e
The game has 200fps cap and is recorded with 240fps, meaning that each frame will have a one step counter value or the same value sometimes. I recorded this game as it was the only one that has a Frame counter metric (instead of a FPS gauge like quake champions 240+fps).

QuoteWhat codec do you use in your videos?

I record with "obs" in mp4 extension. I'm using the "standard" config view so I can't say much from there. The info from avidemux shows  Codec 4CC: H264
I am using all acceleration features, and tried to increase the values where I can, as I have a plenty of resources ( Windows 10x64,i7-6950X,128GB-RAM,RTX2080TI )

QuoteIs it an input device to send keypresses?

Yes, it is a keypress controllers (Microsoft Surface Dial). Really nice experience

QuoteQ and the maximum image buffer for backwards seeking is 16 frames.
R Yes, likely the upper limit, [...]

Makes sense, although this might be an inconvenience when resources are available.
I will compile with some higher values, I really don't mind pushing the hardware to the limits. Same goes with the number of threads settings, not sure if Auto-detect reaches a better number than 32 threads that can be set on custom ( my procexp https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer program does not show more than 16 under both settings, the auto-detect will start with 20 but it will reduce it to 16/13)

QuoteWhen creating future source videos, you should strongly reduce GOP size for H.264 or HEVC or switch to a keyframe-only codec like MJPEG if storage is plentifully available.

Thank you for the tips, I will try to see what other options are available on recording side (Also I will need to teach myself more about video encoding technologies to understand you better )

Always happy to know what other values I can tweak to utilize more resources.
I tried my best to enable all the features that I am aware of, like the CPU Turbo Boost Max that is supposed to prioritize the context switching(non) for this process.
If there are others :)  happy to test them.

eumagga0x2a

The maximum bandwidth of memory transfer may be a limiting factor at such a high fps (~3 GB/s).

klusht

Hi,

I need help regarding compilation from the source.
Flowing the steps present in cross-compiling.txt (building this from a Ubuntu 18 VM)
     I am not able to compile the latest master branch as it is failing with:

-- CPP:Q_mainfilter.h;Q_seekablePreview.h -> ADM_filtersQT5_source=
-- CPP:Q_mainfilter.h;Q_seekablePreview.h -> ADM_filtersQT5_source=/home/klusht/projects/avidemux2/buildMingwQt5-x86_64/ADM_userInterfacesQT5/ADM_filters/moc_Q_mainfilter.cpp;/home/klusht/projects/avidemux2/buildMingwQt5-x86_64/ADM_userInterfacesQT5/ADM_filters/moc_Q_seekablePreview.cpp
CMake Error at CMakeLists.txt:214 (ADD_SUBDIRECTORY):
  The source directory

    /home/klusht/projects/avidemux2/avidemux/qt4/i18n

  does not contain a CMakeLists.txt file.


hence I end up checking a hash from the released versions ( 2.7.4 )  d48b5004a1e20ad653e4562de783761158c63192 that compiles successfully BUT it does not take in consideration the updated value in ./avidemux/common/ADM_editor/include/ADM_edCache.h

The UI shows the same limit of 16 in the preferences window.
Any help is appreciated

Regards

eumagga0x2a

#5
Quote from: klusht on March 30, 2020, 10:23:41 AM
I am not able to compile the latest master branch as it is failing with:

-- CPP:Q_mainfilter.h;Q_seekablePreview.h -> ADM_filtersQT5_source=
-- CPP:Q_mainfilter.h;Q_seekablePreview.h -> ADM_filtersQT5_source=/home/klusht/projects/avidemux2/buildMingwQt5-x86_64/ADM_userInterfacesQT5/ADM_filters/moc_Q_mainfilter.cpp;/home/klusht/projects/avidemux2/buildMingwQt5-x86_64/ADM_userInterfacesQT5/ADM_filters/moc_Q_seekablePreview.cpp
CMake Error at CMakeLists.txt:214 (ADD_SUBDIRECTORY):
  The source directory

    /home/klusht/projects/avidemux2/avidemux/qt4/i18n

  does not contain a CMakeLists.txt file.

You've skipped

git submodule update --init --recursive

after the initial checkout: https://avidemux.org/smif/index.php/topic,18371.msg87089.html#msg87089

Quotehence I end up checking a hash from the released versions ( 2.7.4 )  d48b5004a1e20ad653e4562de783761158c63192 that compiles successfully BUT it does not take in consideration the updated value in ./avidemux/common/ADM_editor/include/ADM_edCache.h

The UI shows the same limit of 16 in the preferences window.

My bad, I've missed a whole lot of things which hardcode the upper bound of 16:

1. avidemux_core/ADM_coreUtils/src/prefs2.conf:27 (at least the last column). After modifying the file, cd into its directory and run

bash update_prefs.sh

2. avidemux/common/ADM_commonUI/DIA_prefs.cpp:301 (optionally but not necessarily also the default value at line 72).

edit: The line numbers above apply to the current git master. I would really strongly recommend to use it instead of meanwhile very outdated release.

eumagga0x2a

By the way, the GOP length in your sample video is 250. So even a four-fold increase of cache size won't even closely approach it.

klusht

Hi,

I got the master branch compiling succesfully and with the changes you mentioned I am able to in crease the cache to 256, but I hit a different problem.

The seeking now is smooth when crossing the 16 frames but I have a lot of frames not decoded (green frames) or badly decoded.
If I set 16 or slightly above all plays fine.

I assume there are more changes for this to work.

How can I help to reach that ? :)


eumagga0x2a

Probably hitting hardware limits, but admlog.txt might contain some clues about the location of the bottleneck.

klusht

[decoderFFDXVA2] 13:06:11-520 Setting up Dxva2 context (instance=00000000076297D0)
[ADM_FAILED] 13:06:11-572 Failed with error code=0x80070057

Is this the one ?

I added the entire file, with the data of seeking through the green frames

eumagga0x2a

Quote from: klusht on March 30, 2020, 01:13:03 PM
[decoderFFDXVA2] 13:06:11-520 Setting up Dxva2 context (instance=00000000076297D0)
[ADM_FAILED] 13:06:11-572 Failed with error code=0x80070057

Is this the one ?

No, this one is completely harmless. It is expected to fail on Windows prior to version 10. Allocation of 278 hardware surfaces succeeds (line 588).

QuoteI added the entire file, with the data of seeking through the green frames

The file doesn't include the entire session and doesn't contain any indications that anything were amiss. Do you get green frames also when simply stepping forward or during playback? Or just only when stepping backward?

eumagga0x2a

I see that you use QtGl renderer. It has a much worse performance than the "DXVA2" (actually, just DirectX) one. Please try it.

klusht

I attached another one with the exit details.

I get green frames every time. When playing, seeking forward and backwards.

eumagga0x2a

Please switch to the DXVA2 video output.

klusht

Sure thing... the other post was ready before seeing your comment.