Don't assume any CLOCK_FREQ value.

Martin Finkel authored 6 years ago and Hugo Beauzée-Luyssen committed 2 years ago

Co-Authored-by: Thomas Guillem <thomas@gllm.fr>

Thomas Guillem authored 2 years ago and Hugo Beauzée-Luyssen committed 2 years ago

My bad, libvlc_time_t is in ms. The timer API should use the sane unit
than libvlc_clock(), that is us in int64_t.

Also add missing vlc_tick_t <-> us conversion (no harm since 1 tick = 1
us for now).

Thomas Guillem authored 2 years ago and Jean-Baptiste Kempf committed 2 years ago

Any LibVLC users could request a timer from the player. This Media Player
timer has its own event API since:

 - It is only used to receive time update points:

 - The timer is not locked by the player lock. Indeed the player lock can be
   too "slow" (it can be recursive, it is used by the playlist, and is it held
   when sending all events). So it's not a good idea to hold this lock for
   every frame/sample updates.

 - The minimum delay between each updates can be configured: it avoids to flood
   the UI when playing a media file with very high fps or very low audio sample
   size.

The libvlc_media_player_time_point struct is used by timer update
callbacks. This public struct hold all the informations to interpolate a
time at a given date. It can be done with the
libvlc_media_player_time_point_interpolate() helper. That way, it is
now possible to get the last player time without holding any locks.

There is only one type of timer (for now):

libvlc_media_player_watch_time(): update are sent only when a frame or a
sample is outputted. Users of this timer should take into account that
the delay between each updates is not regular and can be up to 1seconds
(depending of the input). In that case, they should use their own timer
(from their mainloop) and use
libvlc_media_player_time_point_interpolate() to get the last time.

Thomas Guillem authored 2 years ago and Hugo Beauzée-Luyssen committed 2 years ago

A i_chapters_of_title of -1 mean the current title, so fetch it in that
case.

It fixes a crash while attempting to reach the title array at -1.

Thomas Guillem authored 2 years ago and Hugo Beauzée-Luyssen committed 2 years ago

Asked by API users, more convenient than dropping !selected tracks
ourself.

As discussed on vlc-devel a few years back, it is desirable, if not
sometimes necessary, for media objects to be independent from any given
instance.

A typical reason would be to preparse media in one instance but play
them in another.

The caller ought to be able to select which instance the player should
be instantiated from.

Rémi Denis-Courmont authored 2 years ago and Jean-Baptiste Kempf committed 2 years ago

The caller may want to use a different instance than that which the
media was created from.

This can now be determined unambiguously from the parsed status.

Note that this shifts all the values by one, but binary compatibility is
already broken anyway.

No functional change.

No functional changes.

This remove the old API for preparsed tracks.

Media parsing can occur on any instance, and in all likelihood, a freed
media is not being parsed by any instance.

Note: to cancel parsing, libvlc_media_parse_stop() can be used.

The prototype has changed anyhow, and the variants without options no
longer exist.