Red over blue was against usability rules

Closed captions are in the same SEI user sections
as H264 according to the spec.

No functional changes.

In real use, there are few (typically only zero or one) listeners per
event type. In this case, the linear search through the listener groups
was actually slower than the linear search through the whole list of
listeners: it required one iteration per event type, even for event
types with no listeners.

(Note: using a hash table over the event type would make a lot more
 sense as an optimization.)

The distinction was rather vain, as the inner lock was almost never
held without the outer lock. The only case was adding an event callback
(but _not_ removing one). On the other hand, the distinction required
extra heap manipulations and memory copying for each event.

This fixes excessive (and dumb) usage of thread local variables, and
invalid use of thread cancellation.

This avoids using the buggy asynchronous event queue. This does NOT
solve other existing races and dead locks in the media list player.

As of a2ab8b27, there is always a media
player underneath the media list player.

Setting up font name can't't force font type since
monotype font switch isn't handled by renderer.

fixes the second line background alignment which is always wrong.

All objects with a pointer back to the instance ought to retain a
reference to it (which currently means pretty much all objects).

The following functions are not marked LIBVLC_API and are not in the
public header files (for a reason):
 - libvlc_event_manager_new(),
 - libvlc_event_manager_register_event_type() and
 - libvlc_event_manager_release().
There wer no reasons to have them in the symbols list.

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

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

--
that's what we use everywhere else
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

It was accidentally left out of 130da2a0.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

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