We need to select a format that can be output by the mixer, preferably
the exact format output by the mixer. Keeping the input audio format
breaks for non-linear input formats when S/PDIF output is disabled:
the mixer outputs FL32 that cannot be converted to MPGA, AC-3, etc.
There are two advantages:
- scanning uncached plugins is much faster,
- plugins with broken dependencies are visible in the modules list.
Plugins are still resolved "now" if they are probed by module_need().
This is a safety feature (the run-time linker would exit silently if it
hit an unresolved symbol). As the previous commit unloads all uncached
plugins, we can reload the plugins with different flags as needed.
Plugins with broken/missing underlying libraries will trigger an error
only when used, rather than when scanned. vlc-cache-gen is then a bit
more robust against messed up packages installation (it will not skip
plugins anymore). Also, dialog_Fatal() could be used to report run-time
errors. This was not possible previously: the error would occur before
the UI was started.
Note that this is not implemented on Windows, as there is no support
(that I know) for lazy resolution of DLLs.
Do not keep unused plugins loaded after plugin scan
This saves about 20 Mb of address space, 10 Mb of memory on my system,
when the plugins cache is disabled. It is even more dramatic for
non-VLC apps (as then Qt4 is not loaded).
There is no need to keep this around after the plugins scan. Also,
there is no need to check --reset-plugins-cache if caching si disabled
(--no-plugins-cache).
For error other than congestion (EAGAIN, EWOULDBLOCK, ENOBUFS, ENOMEM),
check the socket type. If the socket is a datagram, retry. Otherwise,
the socket is connection-oriented and we assume the connection broke,
close it.
Use copy/free paradigm rather than hold/release for message items
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).
Jean-Paul Saman [Wed, 11 May 2011 10:14:20 +0000 (12:14 +0200)]
stream_filter/httplive.c: split up parse_SegmentationInformation() function.
Split up parse_SegmentInformation() into two functions: \7fparse_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.
Qt, selector: don't rebuild the model when not necessary...
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.
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.
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.
projects / vlc / log