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,
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 (https://github.com/mean00/avidemux2/blob/master/avidemux/common/ADM_editor/include/ADM_edCache.h#L19).
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.
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 (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.
The maximum bandwidth of memory transfer may be a limiting factor at such a high fps (~3 GB/s).
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
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 --recursiveafter 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.sh2. 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.
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.
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 ? :)
Probably hitting hardware limits, but admlog.txt might contain some clues about the location of the bottleneck.
[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
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?
I see that you use QtGl renderer. It has a much worse performance than the "DXVA2" (actually, just DirectX) one. Please try it.
I attached another one with the exit details.
I get green frames every time. When playing, seeking forward and backwards.
Please switch to the DXVA2 video output.
Sure thing... the other post was ready before seeing your comment.
Yes, thanks. No changes regarding green pictures?
Unfortunately no changes.
The same green frames as before.
The playback and seeking from what I can understand, feels to be done using the same pool of images. Hence I can only suggest that those indexes are not populated with the correct images. Navigation is flawless now through the frames ( only see the short GPU spike/pause after keeping the backwards seek for a long time, assuming the entire 256 frames ).
From a really short read about GOP ... is there a place where I can mention the processing of new frames from the keyframe to be more than 16 ?? if that is a thing ??
Quote from: klusht on March 30, 2020, 02:39:46 PM
The playback and seeking from what I can understand, feels to be done using the same pool of images.
When really seeking (not stepping), the cache is cleared and repopulated starting with the last keyframe prior to the seek point (or from the seek point if the seek target is the keyframe). Stepping forward or starting playback is technically the same.
QuoteFrom a really short read about GOP ... is there a place where I can mention the processing of new frames from the keyframe to be more than 16 ?? if that is a thing ??
I would expect the editor filling the entire cache. Is it not the case?
As before the 240 sample is not playable and it does not produce more than 3 frames after loading the video. Maybe is something wrong with that movie.
Using a 120fps sample and seeking one frame at a time from the beginning I observed the following
the first 19 frames are correctly showing and the 20th one is a green picture and the seeking is very fast meaning that the images have been cached.
After the 20th frame there are many green ones and few SECONDS later in the sample will have badly rendered image for few frames and sometimes a clear one.
All the images are so far retrieved from the cache as there is no visible pause when seeking.
The processing pauses ( assuming cache invalidation / population ) can be seen in the GPU memory utilization spike.
The cache is present and is usable when playing and seeking, the problem, I can assume, is that the data in the cache is not correct.
The green images and the badly decoded ones are present and retrieved on navigation, and never rebuild. Sometimes I see the same frame in multiple places in the cache.
I cannot post them here so here are some external links
20th frame https://drive.google.com/open?id=1gpbu_Hx-ex2daJxEPvuke1GTXdiaBQ7w (https://drive.google.com/open?id=1gpbu_Hx-ex2daJxEPvuke1GTXdiaBQ7w)
Many frames after https://drive.google.com/open?id=1Q-2lUj4Zz9Wg2jLR1AgtWMh1skU3xLSS (https://drive.google.com/open?id=1Q-2lUj4Zz9Wg2jLR1AgtWMh1skU3xLSS)
Hope it helps
After few experiments I found the following when using the 120fps sample
Video display DXVA2 plays like in slow motion and the sound is not in sink, hence I tested the others and they all perform equally well ( although the GPU process % varies but not over 23%)
The output caches size behaves normally if is set to 100 ... and 106 is the maximum I tested that does not produce the green pictures. but on 106 I can observe some "screen tearing" effect when playing at normal speed
Soooo 100 is the sweet spot :) which is a real improvement for the studying process.
Honestly this is the fastest and most performant program for high FPS movies I have ever tested ( I tested a lot of those including premiere/avid/resolve ).
If you feel this cache story is worth improving,
please share how I can support.
Happy to understand what else can be done to push the performance higher as long as there are resources.
I really believe that whoever is using such editors they don't care if is using the entire RAM or 100%GPU/CPU as longs as it is "fast"
Green frames are frames not decoded by the decoder (the graphics card). Block artifacts happen when a reference picture is not available, e.g. when it wasn't decoded. Probably no one ever tried to stress the video decoding pipeline in the graphics card and in the graphics driver that much, so that the particular way how things start to fall apart remained an uncharted territory.
It would be a major boost to performace if someone manages to implement direct HW acceleration on Windows to keep decoded pictures all the time in the graphics card instead of copying huge amounts of data back and forth between the graphics card and the main memory.