GitLab

Adrien Maglo authored Nov 19, 2016 and Jean-Baptiste Kempf committed Nov 19, 2016

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

This lock "protects" two things:
 - The need-update boolean which can more easily be protected by the
   playlist lock.
 - The "node", whose lifetime is not correctly handled anyway.

Make cancellation safe and simplify.

This fixes a whole lot of use-after-free bugs.

Notify as soon as the current input item is changed,
as it is not a good idea to rely on an item-change
eventually happening later.
This will result in some items that are added and played
immediately lacking metadata in their notifications but
this seems like an acceptable edge case.

Controls can be processed if the playlist is empty. They just do
nothing. Conversely, stop need not be processed if the playlist was
already killed.

User interfaces should only add new items under the playlist or the
media library nodes. In particular, they have no business adding or
removing SD items.

This removes the insertion offset parameter to playlist_Add(),
playlist_AddExt() and playlist_AddInput().

intf_InsertItem() was the only occurrence where the offset was zero,
a side effect of how the command line is parsed backward. This is now
done explicitly with playlist_NodeAddInput().

A non-zero positive offset made no sense, since:
 - the number of children of a node can change asynchronously while the
   playlist lock,
 - the back-end asserted or triggered undefined behaviour if the offset
   was out of range.
DBus was the only occurrence of this bug (see also #17451 comment:4),
and has been fixed in an earlier change.

In all remaining call sites, the offset was PLAYLIST_END. This removes
the parameter which would otherwise constitute a useless constant.

 - Handle and report errors.
 - Fix and improve documentation.

This fixes potential assertion failures. Insertion position must always
be valid.

The flag is sort-of-implemented, but never actually used.

They are set but never used. In practice, the (following) position
parameter determines whether the item is inserted or appended. A
positive position means insertion; PLAYLIST_END means appendment.

PLAYLIST_SPREPARSE is not used anywhere. PLAYLIST_PREPARSE is set but
has no effects whatsoever.

Remove items from the arrays takes time, especially during playlist
destruction. In particular removing an item from the current array
requires a linear search and then a memmove(); that was the bottleneck
with quadratic complexity while deleting the playlist. (Now the
bottleneck is removing items from their parent.)

Destroying the arrays early on skips those steps entirely.

Regarding input item look-ups, this reduces asymptotic complexity from
linear to logarithmic time.

Regarding ID look-ups, this reduces insertion and deletion time to
logarithmic. Previously it degraded to linear time because of memcpy()
and memmove() in ARRAY_APPEND and ARRAY_REMOVE macros.

This removes the "all_items" array, and its missing error handlers.

Finally, this adds support for allocating more than INT_MAX items
during the entire lifetime of the VLC instance. (The maximum number of
_concurrent_ items is still INT_MAX, but memory would probably run out
before that is reached.)

Note: Item deletion still requires linear time. And playlist deletion
still consequently requires quadractic time because of the "current"
array.

This reverts commit 6290ebf6.

It behaves badly depending on the CMake Version, and on our buildbots...

LibVLC has zero business messing with process state. This breaks
apps other than VLC and other libraries in the same process.

vlc.exe already depends on kernel32.dll, so there is no need to load it
explicitly. It can simply be looked up.

Regression from e44f6165

Steve Lhomme authored Nov 17, 2016 and Jean-Baptiste Kempf committed Nov 18, 2016

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Steve Lhomme authored Nov 17, 2016 and Jean-Baptiste Kempf committed Nov 18, 2016

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Steve Lhomme authored Nov 17, 2016 and Jean-Baptiste Kempf committed Nov 18, 2016

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Steve Lhomme authored Nov 17, 2016 and Jean-Baptiste Kempf committed Nov 18, 2016

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>