Timshel authored 9 months ago and Timshel K committed 9 months ago

Secondary subtitles cycling is broken because `trackpriv->vout_order`
is never set.

Add `vlc_vout_order` in `vlc_input_event_es` to keep track of it.

Additionnaly to limit modifications when selecting multiples tracks
(Ex: `EsOutSelectList`) we consider that the PRIMARY is always in
first position.

Now they do the same.

Co-authored-by: Alexandre Janniaux <ajanni@videolabs.io>

So we don't need an activate function with varargs. We can call the vlc_filter_open directly.

Only the first 3 elements are the same in filter_t and decoder_t.

This warning is probably wrong anyway.

Use vlc_filter_UnloadModule instead.

It's better suited for filter_t.

It's better suited for filter_t.

As well as an inline function to completely destroy a filter_t.

The close function is called and the deactivate is not, since there should be none.

The activate function should match exactly vlc_filter_open, rather than use
a generic vlc_object_t loader. Then we don't have any dirty cast.

The code is similar to module_need, with better typing.

It's not possible to inline this because we need to call vlc_objres_clear()
for each module loaded unsuccessfully. It's not a public API.

Because of the filter chain, they must have a common way to open them.

Some types of filters may not be used by the filter chain (for example the text
renderer). But still need to be activated the same way. If this ever changes
They will need their own open callback type back.

No functional changes.

So it matches the same Open callback as the other video filters.

All video filters have a priority of 0 because they are loaded by name and
should never be picked as a fallback for other filters.

This video filter is either loaded by name from the command-line or
in vlc_gl_WrapOpenGLFilter().

So it matches the same Open callback as the other video filters.

We don't use module_need() or "video blending".

Thomas Guillem authored 9 months ago and Steve Lhomme committed 9 months ago

Now that both stream and system are compared, we can lower this value.
From 60seconds to 300ms.

Thomas Guillem authored 9 months ago and Steve Lhomme committed 9 months ago

The value is the same, no functional changes.

Thomas Guillem authored 9 months ago and Steve Lhomme committed 9 months ago

We need to compare both stream and system times for discontinuity.
Indeed, a big stream diff is OK if we have the same system diff.
This check is now done after buffering is complete (b_has_external_clock
== true).

Thomas Guillem authored 9 months ago and Steve Lhomme committed 9 months ago

It is read/write from the _dataQueue thread.

Thomas Guillem authored 9 months ago and Steve Lhomme committed 9 months ago

And reset it on the first play.

The whenDataReady() callback could be stuck from a flush.

Thomas Guillem authored 9 months ago and Steve Lhomme committed 9 months ago

From the removeTimeObserver documentation:

"Upon return, the caller is guaranteed that no new time observer blocks
will begin executing. Depending on the calling thread and the queue used
to add the time observer, an in-flight block may continue to execute
after this method returns. You can guarantee synchronous time observer
removal by enqueuing the call to removeTimeObserver: on that queue. Call
dispatch_sync after removeTimeObserver: to wait for any in-flight blocks
to finish executing."

It should not be done during the "make fetch" phase.
For example the "cargo" dependency of DEPS_rav1e-vendor is not taken in account
during the fetch phase.

If there was a previous build left, we should not reuse it.
We do it outside of the target otherwise it's considered the target is already built and won't be rebuilt.

We don't need IDE or debugger support.

This reverts commit 223174d9.

There is no guarantee that RAV1E_VERSION will be defined when rav1e-vendor is included.