VLCKit: Player time callback is relatively infrequent

[deeds]

I'm trying to use VLCKit to loop a portion of a video, without showing any extra frames beyond the provided bounds.
I figured I could pay attention to the mediaPlayerTimeChanged callback, and rewind once I get to the end of the portion of the video that I want to repeat.
Unfortunately it looks like mediaPlayerTimeChanged is only called every 250ms or so— is that the normal behavior? Is there something I could do to get the player's time more frequently, ideally every frame?

Thanks

[MikOfClassX]

see my post: https://forum.videolan.org/viewtopic.php?f=32&t=148843

The aim of slow event notification is probably to save lazy coders from packing events and firing them to a gui (but almost every repaint manager coalesces very frequent repaints()).
What's less clear is why the libvlc_media_player_get_position() is not returning the real accurate position.

I would opt for a silly api extension:
libvlc_media_player_get_position(mediaplayer, bool accurate);
libvlc_media_player_get_time(mediaplayer, bool accurate);

[Jean-Baptiste Kempf]

because the info depends on the demuxing packets. So for audio only or low fps, or low bitrate the updated info comes less often.

[MikOfClassX]

I am confused: libVLC explicitly sets a next_update time delay to 250ms.

For confirmation, I checked the static void *vlc_demux_chained_Thread(void *data) in demux_chained.c:
next_update = vlc_tick_now() + VLC_TICK_FROM_MS(250);

Many developers are reporting the same issue. Is there a way to get a more accurate timing ?

[Jean-Baptiste Kempf]

demux_chained is not the same at all.

[MikOfClassX]

do you mean it has been improved in 4.0 ?

[Jean-Baptiste Kempf]

It will be, yes.

[MikOfClassX]

Ehehe, ok... so it's only matter of time and patience. Any estimation ?

[Jean-Baptiste Kempf]

3 months to be usable.

[MikOfClassX]

Starting timers..