- 11 May, 2011 20 commits
-
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
- remove always zero overruns counter, - constify message pointer.
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
In practice, multiple headers cannot happen. Only VLM input and LUA interface use this hack.
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
Message items are more often than not not rereferenced, and hardly ever rereferenced more than once. Demand-copying will be faster in most common circumstances (especially built-in console or logger).
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Jean-Paul Saman authored
stream_filter/httplive.c: #EXTINF: accepts integer (version < 3) or floating points based on protocol version. Update logic in parse_SegmentationInformation() to accept float values for duration as mentioned in later version of the draft specification.
-
Jean-Paul Saman authored
The variable stream_t *s in function parse_SegmentInformation() was not used.
-
Jean-Paul Saman authored
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.
-
- 10 May, 2011 9 commits
-
-
Jean-Baptiste Kempf authored
-
Rémi Denis-Courmont authored
-
Jean-Baptiste Kempf authored
And remove trailing spaces...
-
Rémi Denis-Courmont authored
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).
-
Rémi Denis-Courmont authored
Currently channels cannot be remapped and samples format must be S16N.
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
This saves two function calls per memset() since there are no optimized implementations of memset() at all.
-
Jean-Baptiste Kempf authored
And this time decode the URI...
-
Jean-Baptiste Kempf authored
This reverts commit 7e1526b9.
-
- 09 May, 2011 11 commits
-
-
Jean-Baptiste Kempf authored
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.
-
Jean-Baptiste Kempf authored
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.
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
It is equal to (module_t.parent != NULL) and hence redumdant.
-
Rémi Denis-Courmont authored
It is always false here.
-
Rémi Denis-Courmont authored
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.
-
Rémi Denis-Courmont authored
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.
-
Rémi Denis-Courmont authored
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.
-
Rémi Denis-Courmont authored
-
Felix Paul Kühne authored
fixes ffmpeg linking issues on some setups and includes latest modplug, etc.
-
Rémi Denis-Courmont authored
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.
-