The VideoLAN Forums

libvlc_media_player_get_time and libvlc_media_player_get_position do not seem to return the exact time of the media.

Imagine a 25fps video playing and calling libvlc_media_player_get_time 10 times a second (intentionally less than the frame rate); a different return value would be expected each time but it seems to return the same value 2 or 3 times before a new value appears.

Is there an alternative way to gain a more accurate current time?

Cheers, Phil.

Additionally, I have implemented a callback function on the libvlc_MediaPlayerTimeChanged event and that only gets call 4 times a second.

Is there anyway to increase this frequency?

Additionally, I have implemented a callback function on the libvlc_MediaPlayerTimeChanged event and that only gets call 4 times a second.

Is there anyway to increase this frequency?

You are lucky already. For some media, that function is stuck on returning the "furthest time position played till" after I call a "set position" to rewind.

The libVLC is bugged in this area, definitely. And there doesn't seem to be much interest in fixing the lib. Only lots of activity in improving VLC itself.

Do note that the "get time" ability works just fine within VLC, beneath the libVLC layer. The claim that VLC itself is built around libVLC may no longer hold true, perhaps stopped holding true when VLC went Qt. Not too sure about that guess of mine, though.

I'm looking to debug libVLC at some point quite soon, perhaps within the next 3 months. Let me know if you want to collaborate. Please don't expect me to fix it all by myself for your benefit. I need all the help I can get.

The libVLC is bugged in this area, definitely. And there doesn't seem to be much interest in fixing the lib. Only lots of activity in improving VLC itself.

Of course. It seems that those using it (including many people in this sub-forum) can only complain and ask for help, but never actually submit fixes.

Do note that the "get time" ability works just fine within VLC, beneath the libVLC layer. The claim that VLC itself is built around libVLC may no longer hold true, perhaps stopped holding true when VLC went Qt. Not too sure about that guess of mine, though.

VLC is built around libvlc, and has been mostly ever since libvlc existed, including in its earlier since then vanished incarnations. You can look for yourself at bin/vlc.c or bin/winvlc.c in the source tree.

But the user interfaces (Qt, Cocoa, HTTP, ncurses) don't use libvlc. Those are plugins for libvlccore, hooking directly into the core, without the libvlc layer.

Additionally, I have implemented a callback function on the libvlc_MediaPlayerTimeChanged event and that only gets call 4 times a second.

Is there anyway to increase this frequency?

Well, there you go. The answer from Remi Denis-Courmont might have answered your question indirectly.

About the only way or chance you're gonna get this to work is to fix the bug in libVLC. Or dive straight into the libVLCCore to get your VLC functionalities. (Either or both of which I am doing in the next 3 months.)

From my experience with other open-source (Apache license mostly) projects, most of us "free-loaders" spend so much time unraveling the core codes, we end up circumventing outer layer API bugs and using core codes directly. We get so familiar with core codes that we forgot to fix the bugs in the API layer over time. Some of us even wrote books on the core codes.

VLC does work wonders, provided you can get around the API layer.

I'm no expert in managing open source projects. But it does seem that LGPL with some form of commercial support package will provide funds for you and I to "complete" the project. Take Qt for example (but I really don't know how successful their commercial package is).

Changing the license is not an option. In 2000, GPL was chosen as (I was not involved and) VLC was only a stand-alone player, not a library. Nowadays, there are too many copyright holders to change it.

With the linux kernel, contributors have been given an opportunity to declare their API code specifically GPL only (EXPORT_SYMBOL_GPL) or else generally it is accepted that symbols can be used in propriety drivers (non GPL) kernel modules. This has been a critical step enabling linux to be used in 1000s of settop boxes, phones and other widely used products where often proprietry drivers are provided by silicon companies because of this flexibility. Could the same be done for VLC contributors to define a subset of LGPL modules? LIBVLC would be a valuable assett in commercial projects in LGPL form, but otheriwse is only likely to get serious attention other than from VideoLan and hobby projects because alternatives such as gstreamer (LGPL) will inevitably be safer bet as a roadmap decision.

Any chance VLC contributors could be polled to get a view if an LLGPL version would be viable?

The kernel way is silly. The kernel is GPL, which means its internal APIs are GPL. Anyway, some developers have rejected the idea of switching to LGPL (not me).

As for commercial support package, that would be counter-productive. There are already very few developers. If they were to set up a company and do administrative and commercial work, there would be none left pretty soon. In my opnion, this really should be up to companies and entrepreneurs, not existing developers.