GitLab

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>

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

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

The previous implementation would crash given that p_sys->p_video and
p_sys->p_audio is not guaranteed to be non-NULL (they can be NULL due
to an unsupported codec).

These changes simply make sure that we do not try to send blocks that
do not have have a corresponding ES (causing a crash).

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

If neither video nor audio track can be played, these changes make
sure that we do not waste our breath demuxing a stream that will not
output anything.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

It is more helpful to know whether the unsupported codec is video or audio, and
given the seriousness of the matter; an error or is more appropriate than a
warning.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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

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

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

Simple fix of typo in the include-guard so that it actually does what
it is supposed to do.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Ref #3353

Signed-off-by: Thomas Guillem <thomas@gllm.fr>

There isn't a case where program[0] is 0 and program[1] is 0. They are always
created together. So the second part of the if() is never called.

program[0] is for YUV and XYZ sources so it is odd to use it with a single
planar texture, given that's what program[1] is for.
Signed-off-by: Thomas Guillem <thomas@gllm.fr>

Signed-off-by: Thomas Guillem <thomas@gllm.fr>