Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CALL SEEK #1086

Closed
5opr4ni opened this issue Sep 25, 2018 · 3 comments
Closed

CALL SEEK #1086

5opr4ni opened this issue Sep 25, 2018 · 3 comments
Labels
Milestone

Comments

@5opr4ni
Copy link
Contributor

5opr4ni commented Sep 25, 2018

Expected behaviour

CALL 1-10 SEEK 123 should go to frame 123

Current behaviour

If you fire off a call like the command above and do that in a sequence as if you joged a jogwheel and sent the values. (123, 124, 125, 126......) The result is a bit unpredictive, it advances but it jumps back and forth in time, and the other ways to do a seek, like rel, in, out is also unpredictive.

Have a look here!
https://youtu.be/rvsemtNNfvE


Steps to reproduce

CALL 1-10 SEEK 123
CALL 1-10 SEEK 124
CALL 1-10 SEEK 125
CALL 1-10 SEEK 126


v2.2 Beta 9 x64
Win10

@ronag ronag added this to the 2.2.0 milestone Nov 3, 2018
@ronag
Copy link
Member

ronag commented Nov 3, 2018

@5opr4ni can you send me a good file to test with?

@5opr4ni
Copy link
Contributor Author

5opr4ni commented Nov 3, 2018

Hi @ronag

I will wetransfer a file 720p50 with framenumbers in it so that you easier can see the issue.
750 Frames long.

Play the video:
PLAY 1-10 VALVAKA_SHORT

Pause it:
PAUSE 1-10 (If you don't pause the video, it works better, but you don't see the problem then.)

Do a Call:
CALL 1-10 SEEK 500

Received message from 127.0.0.1: REQ 9c73e31f-c3d4-4eba-82f1-8246c8b98259 call 1-10 seek 500\r\n
Sent message to 127.0.0.1:RES 9c73e31f-c3d4-4eba-82f1-8246c8b98259 201 CALL OK\r\n500\r\n

The thing that happens is that the video jumps a couple of frames forward although the CALL OK reports that it has jumped to the seeked frame.
The OSC also reports the wrong time here. (Could this be the same manifestation problem as in #1102 )

Do another Call:
CALL 1-10 SEEK 501
Now it jumps to (near) the new location. (The number 24 seems to have a significant meaning, I don't know what tough. ;) )

And then try this several times:
CALL 1-10 SEEK REL +1
And it cycles trough some other strange frames.

Played around with these and the same strange behavior.
CALL 1-10 SEEK in 300
CALL 1-10 SEEK end -300
CALL 1-10 SEEK rel -100

The thing I can see clearly is that the first seek command absolutely don't do what it should but the second seek gets you close to what you want.

If you do what Issue #1102 says, you still get time 0.0 in both OSC and in INFO 1-10, but you end up in the correct frame.
LOAD 1-10 VALVAKA_SHORT SEEK 250

Last thing: If you have reached the last frame, SEEK doesn't work.

/o

@5opr4ni
Copy link
Contributor Author

5opr4ni commented Nov 10, 2018

Now SEEK works as expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants