The VideoLAN Forums

I notice that starting w/ v2.0, the call to libvlc_media_player_get_time gives undeterministic time. I have a need to know precisely what time is VLC currently on (+/- 10 ms desired). In v1.1, the call to libvlc_media_player_get_time always give T where T is {exact time in VLC or smaller than the exact time}. This behavior is desired because I can estimate easily what the time is using my own clock and sync with VLC time at key frames where the exact time is returned.

In v2.0 and 2.1.1, it seems like T is {plus or minus N from the exact time}, where N is between 0 and as much as 200 ms. Unfortunately, I don't have a way to estimate the time when T is behaving like this.


Can anyone shed some light on this issue? Is it possible to fix VLC to return the time as in v.1.1?

Is that the case when playing?

Yes. I tried to use the Position and the Length to compute the Time instead and this method has the same issue.

I also stumbled upon the same problem today, and I am tearing my hairs trying to understand what goes wrong. My tests show the same behaviour in versions 1.1.11, 2.0.1, and 2.1.2 (no others tested).

Basically, if I use libvlc_media_player_set_time to 0 and directly after query for the time with libvlc_media_player_get_time, everything is fine. BUT if I wait a few hundred milliseconds before querying, the value changes as tommy382 describes.

The same behaviour has been reported before:

https://forum.videolan.org/viewtopic.php?f=32&t=107168

In my case the same offset of "190" is observed, regardless of what time value I set initially. I wonder if this is an error on my part, or if others have seen the same problem, and if so how it was solved.

*edit*

This issue is also maybe related:

https://forum.videolan.org/viewtopic.php?f=32&t=116679

Is this with mp3 too?

Sorry for the slow answer; other work came in. My post before missed the fact that tests were done on h.264 video in mp4 containers. I rewrote my test code to exclude all other stuff, and tested with two different MP3 files instead (320 kbps CBR). Results are similar: first I set the time to 0, and query directly. The time returned is "0". Then I set the time to 0, wait for a while (2s) and then query. The time returned is "16", and that offset follows regardless of what time I set.

(For the MP3 files, the file duration differs from what I think it should be, but I didn't see that problem with videos. I use ffprobe to compare metadata results.)

My case was on mp3 and mka files. I haven't test w/ video files but I assume it has the same issue.

This issue still exist in VLC 2.1.5 and the latest 2.2 nightly build for MKA files. However, it looks like the issue is fixed on mp3 files. Was there any ticket open for this? I wondered if it was closed w/o testing on MKA files.

MKA with large segments will be not precise, indeed.