These buffers aren't known to the actual OMX codec.

Normally, these buffers are removed from the queue by
DecodeAudio/DecodeVideo, but if they're pushed multiple
times (which happens when using google sw decoders),
PortReconfigure might try to free them.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

These buffers were introduced to avoid a potential deadlock
when the codec has issued a PortSettingsChanged event but
not returned any buffers to the client, making the DecodeVideo
function hang waiting for an input buffer to use, before
handling the reconfigure. The same handling needs to be done
for DecodeAudio too, otherwise it will try to use the
sentinel buffer as a normal one.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

This SetParameters call shouldn't be necessary as far as I know,
but only avoiding it for audio codecs for now.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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

This is similar to the ThumbnailMode on Nexus S, except that
the index doesn't seem to be queryable dynamically
(I don't seem to find any string in the binaries that
would be the right one at least).
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>

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

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

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

Setting libupnp's maximum content length to zero makes it unable to
fetch any didl instead of the probably expected unlimited behavior.

* Accept any version of the MediaServer service
* Browse the advertised ContentDirectory service version
Signed-off-by: Mirsal Ennaime <mirsal@videolan.org>

$enable_speex can't be empty at this point so this check makes no sense

According to http://upnp.org/specs/av/UPnP-av-MediaServer-v1-Device.pdf, the tag name of the element
that provides the base URL for relative URLs is "URLBase". The same is true for a v2 MediaServer.
Make it so in MediaServer:: parseDeviceDescription().
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Close #5675

Because ExecuteCommand allocates temporary string space on the stack,
proportional to the length of the command to execute, a stack overflow can
occur when the the command is too long.

This can be triggered remotely e.g. from the VLC Web interface, by
running this JavaScript:

sendVLMCmd(Array.prototype.join.call({length:300000},'a'));

which sends a string of length 300000 to ExecuteCommand, crashing VLC.
OKed-by: Rafaël Carré <funman@videolan.org>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

The iomx loading stub doesn't use the library name.
If there's errors in loading the function pointers, this
gives slightly more correct error messages.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

These aren't necessary any longer.

The approach of adding private headers to the build of the VLC
core doesn't work well if one wants to target multiple private
ABI versions in one build.

Instead, small shared libraries for each private ABI version
can be built separately.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Building the iomx version of the omxil module itself doesn't
require the private headers any longer, they're only necessary
when building the iomx wrapper code (which should be built by the
NDK makefile instead).
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

The separate shared library needs to be loaded into the process
before using the iomx module, preferrably by the java part
of the android application.

This allows building the iomx glue code for a number of different
ABI versions, and additionally avoids linking the main VLC
library to any private symbols that might make it unloadable.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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

This reverts commit acb6ff18.

This reverts commit 4e03fb4f.

This deals gracefully with and warns about the legacy
--http-host <host>:<port> and --rtsp-host <host>:<port>/<path> syntaxes

Close #5694

Previously QToolButtonExt had some undesirable edge case behaviour.

Firstly, once the user presses down on a QToolButtonExt there is no
way to cancel the action; either a short or a long click will be
generated. Compare this to a normal button, which can be cancelled by
releasing the mouse outside of the button area.

Secondly, with the mouse button held down, moving the mouse in and out
of the button area will generate multiple short click events, when no
event at all is desired.

This patch corrects this: by releasing the mouse outside the button area
no event is generated; additionally no short click events are generated
simply by moving the depressed mouse in and out of the button.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>