[BUG] Collect key frames does not work

[The_Tinkerer]

Using Hybrid dev version 2020.10.20.1

Go to Config -> Internals, enable Cut Support, select "Collect key frames" and "always".

Load a video file. Key frames are not collected.

Happens on any video file I've tried so far. Here's one I used:

https://drive.google.com/file/d/1xpuk-Vx...gl3BAvBiCd

[Selur]

I'll look into it.

[Selur]

Tried to reproduce with your file,..
Log shows "Grabbing key frame positions from current video stream for better cut support on passthrough,..."
Hybrid does call:

ffmpeg -i C:\Users\Selur\Desktop\Test.mp4 -vf select="eq(pict_type\,PICT_TYPE_I)" -vsync 2 -loglevel debug -an -sn -f null -

And from the output (see attachment) there is only one IDR frame in the stream.
All other I frames are non-IDR frames and thus no key frames.

[Parsed_select_0 @ 000002697ff98e80] n:46.000000 pts:46046.000000 t:1.534867 key:1 interlace_type:P pict_type:I scene:nan -> select:1.000000 select_out:0
[h264 @ 0000026901533f00] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 2

-> so I don't see a bug here.

Cu Selur

[The_Tinkerer]

Comparing to Hybrid 2020.02.19.1, in that version, I see key frames when I enable "Collect key frames" and "always":




In Hybrid 2020.10.20.1, I don't see that list:




When I load the mp4 file in 2020.02.19.1, I see a progress bar with "FFmpeg" in it go from 0 to 100% in about 5 or so seconds.

When I load the same file in 2020.10.20.1, I don't see that progress bar. The file loads immediately.

It looks like it is actually collecting key frames, but it doesn't display the list. I mistook that for not collecting key frames at all.

Log files:

[attachment=1101]
[attachment=1102]

[Selur]

I'll look into it,..

[Selur]

Rewrote the code, should work now.
Send you a link via PM.

Cu Selur

[The_Tinkerer]

Took me some time to get back and test this!

Using Hybrid dev 2020.10.27.1.

Two bugs / problems I found...



One:

It seems that the drop down list does not show all detected key frames. The key frames it shows and misses are different each time it is run.

On the Test.mp4 file I posted above:

One instance:

[attachment=1103]


Another instance:

[attachment=1104]


Didn't do anything different in each instance, just enabled key Cut Support, Collect key frames, and always, and loaded the file.



Two:

Trim support in VapourSynth does not work when QTGMC is enabled. It doesn't matter what settings are used; if QTGMC is in the script along with Trim, VapourSynth crashes.

It works fine with AviSynth.

I checked, and this problem actually existed in the 2020.10.20.1 dev version, before the 2020.10.27.1 update.

Not sure if this is a fixable bug, or if maybe it's not possible to use QTGMC with cut support in VapourSynth?

Logs:

[attachment=1105]
Used Test.mp4 file above. Used VapourSynth. Overwrote input to Top Field First, enabled QTGMC on Deinterlace tab. Enabled Cut Support, Collect key frames, and always. Selected a start key frame from the drop down past the beginning, at around the 2 minute mark. Crashes on preview or job process. (Log has job process.)


[attachment=1106]
Same as above, but instead enabled QTGMC from VapourSynth Denoise tab. Crashes on preview or job process. (Log has job process.)


[attachment=1107]
Used Test.mp4. Used Avisynth. Overwrote input to Top Field First, enabled QTGMC on Deinterlace tab. Enabled Cut Support, Collect key frames, and always. Selected a start key frame from the drop down past the beginning, at around the 2 minute mark. Works as expected on preview or job process. (Log has job process.)

[Selur]

I see the problem with the cutting.
In Vapoursynth the cutting is placed before QTGMC and since your deinterlacing changes the frame count the cut is to large.
(Never encountered it since I rarely cut and I rarely deinterlace.)
-> I'll add the Trim the 'Filter Order' list in Vapoursynth this way the user can decide.

Key frame detection looks more problematic, since FFmpeg seems to return different outputs. :/
(as side note: always grabbing key frame isn't really necessary if you reencode the video)

Cu Selur

[Selur]

Nope, the trim(..) call has a mistake instead of when using 'length=' I didn't use the length, but the last frame. DOH

[Selur]

Okay, the key frame extraction is driving me crazy.
When I use:

ffmpeg -i E:\Test.mp4 -vf select=eq(pict_type\,PICT_TYPE_I) -vsync vfr -loglevel debug -an -sn -f null -

multiple times inside a Windows Command Prompt I always get the same output.
But when calling it through Hybrid, I get a different output nearly every call. WTF?!

I tried modifying the analysis of the data to redo the scan when a key frame with invalid timing infos was encountered, which lead to

Grabbing key frame positions from current video stream for better cut support on passthrough,...
Redoing key frame detection call since non valid time stamps were detected.
detected 69 valid and 1 invalid keyframes
Redoing key frame detection call since non valid time stamps were detected.
detected 33 valid and 2 invalid keyframes
Redoing key frame detection call since non valid time stamps were detected.
detected 34 valid and 1 invalid keyframes
Redoing key frame detection call since non valid time stamps were detected.
detected 32 valid and 4 invalid keyframes
Redoing key frame detection call since non valid time stamps were detected.
detected 29 valid and 1 invalid keyframes
-> detected 26 keyframes

So this will take some more time.