The VideoLAN Forums

Hello,

I am working on a hobby media player on Windows using libVLC 2.0.1 and I have a specific question on how to determine the duration of the media being played.

In my player, I use a slider control to model the duration and the progress of the media to be played. Currently I rely on the "libvlc_MediaPlayerLengthChanged" callback event to determine the duration. Specially, when this event is triggered as soon as the media is played, then I call "libvlc_media_player_get_length" to retrieve the length of the media and set the slider to that duration. I have experimented with many media format, like mpg, flv, mov, mp4 etc, they all work alright in the sense that the "libvlc_MediaPlayerLengthChanged" callback event is triggered once or sometimes a few times at the beginning of the playing and then no longer triggered while playing the rest of the media. However I encounter a problem when playing some mp3 files, the "libvlc_MediaPlayerLengthChanged" event will be triggered many times, not only at the beginning of the playing and sometimes even in the middle of the playing. This becomes a problem as it keeps resetting the the slider control.

Here is some info on one of the mp3 files I played for example. It has a constant Bitrate: 128 kbps, Sample Rate: 44100 and Number of frames : 131187, ie. about 57 minutes.

When that file is played, here is a list of "libvlc_MediaPlayerLengthChanged" with different length retrieved, in milliseconds"

3426926
3426979
3426960
3427033
3427006
...
3426952
3426979
3426952
3426979
...

As illustrated above, after initial 4 or 5 seconds, it will stabilize at 3426952 for a while but then from time to time it will change again. One obvious solution is to calculate the delta between each consecutive length changes, if the delta is less than one seconds (1000 ms) then the change can be ignored and this solution works fine. But my question is if this is the right way of doing it ? Would this solution work for variable bitrate mp3 files ? As I tried playing the same file using VLC player, it does not appear to suffer this issue and the duration stay the same. So I wonder how it is done in VLC player.

Has anyone experienced the same issue and how you solved it ?

Thanks a lot.

I noticed over last week there were 49 views of my post but no one replied. Now I wonder if this is a bug in libVLC. As with fixed bit rate and the same file being played, there should not have "libvlc_MediaPlayerLengthChanged" event being triggered beyond the first few seconds, supposing libVLC was scanning through the file to determine the duration during that initial stage.

Any libVLC developer who has insight into this ?

Try reimplementing your slider control so that it is not dependant upon the actual length of the media. Say, a range of 0.0 to 1.0, where 0.75 would be 75% of whatever the length happens to be. Works for me.

Hi Michael, thanks for the reply. Even with your approach, don't you still need to translate your slider position to the real length value of the media if you drag your slider for random seeking ? If the real length fluctuates from time to time, then the translated seek position could not be accurate.

No as libvlc_media_player_set_position() takes a float for position, and one which is the same scale as what the slider provides (0.0 to 1.0).

Incidentally; my software listens for the libvlc_MediaDurationChanged event, then takes the value in 'event->u.media_duration_changed.new_duration' as the length. Nowhere do I use libvlc_media_player_get_length().
Apart from displaying the actual media duration on screen, the only other occasion that length is used is to calculate the chapter marks' location during rendering.

Hi there - I got the same problem however when encoding direct stream (via dshow://) into h.264, the resulting movie.mp4 file has no length (libvlc_media_player_get_length() returns 0, not -1). When positioning (using the slider in standard VLC player, V1.1.11, I get lots of artifacts, but positioning works kind of. Seems to me VLC has difficulties estimating exact position in base-band given the variable bitrate of the encoded file... maybe some pro can confirm so I don't have to dig further thanks!
andy