This is bug compatibility for XVideo drivers that scale the whole
picture rather than the source rectangle (the XVideo 2 specification
does not really state which behaviour is correct).

This works because the video output core only applies crop parameters
*after* the vout display plugin is activated. This is brittle though:
the A/R and crop parameters should probably be passed as configuration
like zoom.

```--
  CCLD     libaccess_mms_plugin.la
weakld: error: Unresolved symbol (UNDEF) '_vlc_poll'.
weakld: info: The symbol is referenced by:
    P:\tmp\ldconv_libaccess_mms_plugin_la-mmstu_38da54703f4316fd10.obj
Ignoring unresolved externals reported from weak prelinker.
Error! E2028: _vlc_poll is an undefined reference
file P:/tmp\ldconv_libaccess_mms_plugin_la-mmstu_38da54703f4316fd10.obj(ldconv_libaccess_mms_plugin_la-mmstu_38da54703f4316fd10.obj): undefined symbol _vlc_poll
```

--
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

We can only have 512 LocalRefs, so don't leak them.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

It should fix a possible invalid memory access

When streaming ogg-files via rtp, an ogg-file can trigger an invalid
write access using an overly long 'configuration' string.

The original code attemps to allocate space to hold the string on the stack
and hence, cannot verify if allocation succeeds. Instead, we now allocate the
buffer on the heap and return if allocation fails.

In detail, rtp_packetize_xiph_config allocates a buffer on the stack at (1) where
the size depends on the local variable 'len'. The variable 'len' is
calculated at (0) to be the length of a string contained in a specially
crafted Ogg Vorbis file, and therefore, it is attacker-controlled.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

On 32 bit builds, parsing of update status files with a size of
4294967295 or more lead to an integer truncation in a call to malloc
and a subsequent buffer overflow. This happened prior to checking the
files' signature. The commit fixes this by disallowing overly large
status files (above 65k in practice)
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>

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

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

demux/mp4/libmp4.c:858:12: warning: variable ‘translate’ set but not used [-Wunused-but-set-variable]
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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

We ensure that pbox->i_size is never smaller than 8 to avoid an
integer underflow in the third argument of the subsequent call to
memcpy. We also make sure no truncation occurs when passing values
derived from the 64 bit integer p_box->i_size to arguments of malloc
and memcpy that may be 32 bit integers on 32 bit platforms.
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>

This reverts commit 67066bf6 and
1a2780cb as there are still some
upstream issues to resolve.

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Check the return value of malloc to avoid a null-pointer dereference.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

The variable len is a raw 32 bit value read using GetDWBE. If this
value is larger than UINT32_MAX - sizeof(eos), this will cause an
integer overflow in the subsequent call to malloc, and finally a
buffer overflow when calling memcpy. We fix this by checking len
accordingly.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

If we provide initial segment-number, most likely we want to continue
where we have left of, so leave old playlist-file there and just
overwrite it when we updated it.

default initial-segment-number is 1 so don't test against 0

If provided initial-segment-number option, signal discontinuity so
player knows to reset timestamps etc for new segments.

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