This led to a random crash when resizing video on a small display (or when
resizing small video).
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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

Use getInputBuffer and getOutputBuffer instead of getInputBuffers and
getOutputBuffers.

see http://developer.android.com/reference/android/media/MediaCodec.htmlSigned-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Fail only if a critical method is not found.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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

Starting API 21, the way to know the number of output buffers is deprecated.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Mostly to remove "#include <iphlpapi.h>" which is unecessary, and can
break
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

This fixes corking especially.

This function already starts playback if stopped (and as far as I know
it always has).

This function already checks if the playlist is running internally,
in which case it has no effects.

Those two functions have no effects if the playlist is stopped.
Otherwise they force the playlist to playing ("running") or paused
state respectively.

As a reminder, the existing playlist_Play() forces the playlist into
running state (unless it is empty), and playlist_Stop() forces the
playlist into stopped state (unless the input thread refuses to die).
There are no functions to force the playlist to paused state.

The behaviour is unchanged:
 - if stopped: starts playing,
 - if playing: pauses playing,
 - if paused: resumes playing.

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>