Delay in "seek" response.

[rew]

I'm working on a project on a raspberry pi where we'll seek often and the user should see as little delay as possible, i.e. from button press to new location playing the delay should be as short as possible.

I've tried omxplayer and it seeks pleasantly fast. About 300 to 500 ms of delay between pressing the button and the new part playing (human doing the "measuring", so lots of tolerance).

But omxplayer is deprecated on raspberry pi 4, and they suggest to use VLC. [s] (another reason for me to want to use VLC is that omxplayer doesn't seem to support seek xxx yet. I'll make that if necessary, but as VLC already has it, it would be easier to just use VLC... ) [/s] Wrong. I just stopped reading right before that was explained.

The problem is that VLC seems to take about 2000 ms after a seek command (while issuing "main decoder error: buffer deadlock prevented") before starting on the new part of the video. That's too long for my application. Is there a way I can reduce the delay from the "seek" to the new part of the video starting to play?

[james0001]

Dear Sir, I have exactly the opposite problem (see my post entitled 'Option to set a small delay after pressing play/pause etc'). How does one change the speed of response to keypress? Have you had any joy?
James

[rew]

I remember I delivered the product. Not sure what I did to get acceptable performance.

Inserting a delay is "easy" Catch the keypress externally, delay and then reissue the kepress to the application. Or find the source, find where keypresses are processed and insert a delay depending on what key is pressed.