Many people don't care about NPAPI and it's hard to build

This reverts commit 937911d5 which was
obsoleted by commit 0fd580b8c0f1590d2b01a5062b4a1d616cd80e1c.

Also covers #2575 and #11514

I don't really see how this can happen, but it should fix it.

Close #13190

Close #12888

Or just ugly in some themes

Unfortunately, this can cause a slight offset of the colour planes if the
top/left crop offset is not a multiple of the subsampling ratio.

This reverts commit 44d4685b.
When using a scaling algorithm other than nearest neighbor, this change
caused the picture padding to be scaled with the video.

This moves Direct3D on Windows (with no effects on actual order) and
OpenGL on Linux/BSD (now exceeding XVideo thanks shaders and blending).

It remains to be decided whether OpenGL should be increased on Windows;
in principles, it should have a higher priority than D2D and DDraw.

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>