Split up parse_SegmentInformation() into two functions:
parse_SegmentInformation() - parse #EXTINF to get duration
  parse_AddSegment() - adds new segment

The parse_SegmentInformation() did both functions before and this
made some HTTP Live URL not work as expected. The splitting up of
these functionalities solves this issue.

And remove trailing spaces...

This is not tested due to lack of use cases. Please test and report
bugs or limitations BEFORE final 1.2.0 release (or shut up).

Currently channels cannot be remapped and samples format must be S16N.

This saves two function calls per memset() since there are no optimized
implementations of memset() at all.

And this time decode the URI...

This reverts commit 7e1526b9.

This should fix the build-twice-the-model issue and should avoid
rebuilding when clicking the already selected one.
Rebuilding the model is costly enough in time, to not do it all the
time.

First, I ain't sure we should display the mrl and not a "nice version of it"
Then I ain't sure that we should elipse on the left...
But, this is a beginning... Improvements welcome.

It is equal to (module_t.parent != NULL) and hence redumdant.

It is always false here.

On the one hand, plugins from different architectures cannot be mixed
in the same installation directory as they have the same names.
On the other hand, endianess and type sizes is way insufficient to
discriminate architectures (e.g. armel and i386 look the same).

So this was totally useless. And it did not need to be formatted at
run-time either.

The plugin cache does not depend on this anymore. It always contain all
plugins like it did in VLC versions <= 1.0. In theory, it could even be
generated at build-time if:
 * the compilation is native, and
 * the set of installed plugins is invariable.

On x86, describing and probing optimized plugins is safe (thanks to the
removal of the -mmmx and -msse2 compiler flags).

On PowerPC, libvlccore is built with -maltivec. This is a bug (no
difference before or after the plugin directory hack).
Describing and probing Altivec plugins is no worse.

On ARM, NEON support is detected only at compilation time currently
for lack of a better alternative. So this is a non-issue.

fixes ffmpeg linking issues on some setups and includes latest modplug, etc.

x86 GCC does not need those parameters to compile MMX or SSE assembly
or built-in intrinsics (contrary to ARM GCC w.r.t. NEON). They only
allow the compiler to issue MMX or SSE instructions for the plain C
code. We already rely on this tolerant compiler semantic for the CPU
detection code, and for some optionally accelerated filters (e.g.
deinterlace).

Disabling MMX and SSE for non-assembly code should have no or
negligible effects on the affected plugins. On the other hand, it
ensures that the plugin descriptor can be run by non-MMX/non-SSE CPUs.

Same as is done for MMX. Run-time checks determine whether SSE can be
used in any case.

Sorry for the problem.

This still needs a lot of fixing
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>

So at least, someone can test/fix it...
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>

CLose #4298

Should fix the issue mentionned on #3816, comment 14, 2 last results...

10l