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>

improve locality, remove memset and useless labels, add unlikely post
allocations

Do not malloc 900Mb, for example...

Close #5689

Tested on iOS devices
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 is counter-intuitive.
As asked by etix

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