May 14, 2021, 10:12:22 PM

News:

--


Playback and seek on high 240fps

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

Previous topic - Next topic

eumagga0x2a

Yes, thanks. No changes regarding green pictures?

klusht

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 ??

eumagga0x2a

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?

klusht

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
Many frames after     https://drive.google.com/open?id=1Q-2lUj4Zz9Wg2jLR1AgtWMh1skU3xLSS

Hope it helps

klusht

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"

eumagga0x2a

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.