Server: CALL SEEK

[5opr4ni]

After interlaced changes in the core, the FPS for a video is 50fps. (on 1080i5000 channel.)
This makes it hard to know how to enter the framenumber with CALL and SEEK.
It's easy, multiply by two, but illogical. ;)

[premultiply]

And if you have multiple channels with different framerates it is even more complicated.
I would prefer seeking and length parameters in time units and let the producer calculate the correct frame position based on it.

[5opr4ni]

@premultiply I am not sure about that. the server itself should have the highest granularity, but in some way we want to abstract that from the users. I think this is something for the future. there should be an abstraction layer between the server and the user, serverside. We have spoken about that and the possibility to have AMCP as a dynamic protocol, so that you could implement a version of for example
CALL 1-10 SEEK END -125
that could have an alias like
LAST 4.5 SECONDS
Just a silly command, but you get the idea.
But anyway the core has to be logical, and thats the hard part.

I don't know, but this could be an initial call for the future of AMCP.

[ronag]

I think we could just add a suffix syntax? "CALL 1-10 SEEK 10s" or support timecode syntax "CALL 1-10 SEEK 00:00:10.00" (hours:minutes:seconds:fractions)

[5opr4ni]

For now that could be a solution.
+1 timecode

[ronag]

@5opr4ni could you create a separate issue for 3.0? I'm closing this. It's fixed.

[premultiply]

I would prefer the "timecode" solution with fractions

[premultiply]

Maybe it would be also easy to parse _seconds.fractions_ next to _hours:minutes:seconds.fractions_

[5opr4ni]

@ronag How did you fixe this? I do still need to calculate the channel as if it is 50p.

To reach frame 1900 I have to call 1-10 seek 3800

Is that correct understood?

I have forgotten to write this down.

[ronag]

yes, in interlaced you seek to fields