GitLab

As any function that requires a valid playlist item as parameter, the
function can only make sense with the lock already held by the caller.

It is declared in <vlc_playlist.h>.

Nodes are not supposed to have real input items. The parameter was
always NULL, except when copying another node, in which case it did not
matter whether it was or was not NULL.

as found here https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.mdSigned-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Leave an alias in url_parse() for compatiblity for the time being.

Since that's now using ARRAY_SIZE

Same usage as binary data

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

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

fixes #17608
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>

Replace the usage of legacy helpers with ones where common
functionality is shared, effectively avoiding code-duplication.
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>

The helper functions currently present in the relevant files are a bit
too broad, leading to duplicate code in terms of functionality.

These changes introduces three new helper-functions that will be used
to refactor/replace the legacy implementation.
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>

MP4_ReadBox_String is invoked for boxes that contains raw
byte-content, though there is nothing saying that this raw-byte
sequence does not contain a null-byte ('\0').

If the sequence contains a null-byte, then there is no way (in the
previous implementation) for things working with the box-content to
access data that follows it (given that one cannot know if the
null-byte is the end-of-data terminator, or simply part of the
payload).

These changes make sure that the entire contents can be accessed by
including the length of the contents in MP4_Box_data_string_t.
Signed-off-by: Francois Cartegnie <fcvlcdev@free.fr>

ID3D11VideoDevice::CreateVideoDecoderOutputView() crashes when the texture has
more than 30 slices. Luckily we never need more than that.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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

It was broken when ProtoBuf 3.1 was installed system-wide, for example.

The bootstrap script that outputs which binary tools need to be installed, incorrectly
detects that Protocol Buffers 3.1 is a compatible version with 2.6. This changes the
check on the major version number to require it to be same, not just bigger,
since changes on the major version numbers might be breaking changes, as was the case
here.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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

After complete migration to github
http://www.openjpeg.org/2015/07/19/github-migration-and-new-website
the old download links do not work.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Fix #3353

Otherwise CMake doesn't understand properly it's cross compiling
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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

otherwise the antique automake 1.8 is used
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>