Goto Time correction + speed improvment

[hinterwaeldler]

Hi,

while taking a look into the GotoTime handling, i've recorginzed, that it is only capable to search for the next IntraFrame before the given time. This includes searching for an IntraFrame.
The two patches applied correct this behaviour, that the search for an IntraFrame time leads to the requested IntraFrame.

The first only corrects this behaviour.
The second corrects this behaviour and replace the IntraFrame search with the quick search algorithm, at least the part which covers the determination of the current frame and continuous with a linear search for the IntraFrame before.

DO NOT APPLY BOTH
I've tested the second one with a couple of values/combination and should work. Hope i have not missed something

Btw. was the behaviour expected, that GotoTime only covers the search for the next IntraFrame?

Greets
Hinterwaeldler

[mean]

The 2nd one looks good, it should be faster (is it noticable)

The use case that is weird is the following:
You are sitting on keyframe @ 27000
you press previous keyframe, so we want the one BEFORE 27000, excluding it

[hinterwaeldler]

The use case that is weird is the following:
You are sitting on keyframe @ 27000
you press previous keyframe, so we want the one BEFORE 27000, excluding it

The method is called in the same way, when pressing C+t or click on the time button in the gui -> Maybe there is an additional parameter necessary.
After a short test: yes both patches break the search for the last keyframe. I will have a look at it and modify the patch accordingly

Within gdb the difference is noticable, but this might be related to the inserted printf parts which i have appended while writing it. Thinking about a larger avisynth script as input, there should be a large difference, but not verified

[mean]

Normally the speed up should be limited
we only deal with metadata; no decoding done

[mean]

Committed with a little change to deal with the case described above
Thanks!

[hinterwaeldler]

Hi

as the last patch did not cover the jump to any given frame (independent of it's type) i've reworked the initial work based on the current state within the git repository.
Maybe it's a good idea to rework the search for the next frame in a way close to the original part.

Hope I did not break any wanted behaviour this time

Greets
Hinterwaeldler

[mean]

Thanks, the patches are in the queue, will commit them soon
( and sorry for the delay)

[hinterwaeldler]

Thx and no problem for the delay, just finished the patch a few hours before