Place a black background behind caption text.  We cannot use the
existing "background" feature for subdecoders because it fills the
entire subpicture block, and in the case of the EIA-608 decoder
would result in a large square (since we send all lines to
the subpicture decoder even if they are blank).  This approach
allows for rendering of the background even in such cases, while
preserving proper layout of the captions.
Signed-off-by: Rafaël Carré <funman@videolan.org>

Update audio_format_table to allow selection of OMX
components which support mp3, vorbis or wma role.
Signed-off-by: Rafaël Carré <funman@videolan.org>

OMX.STM.Video.Decoder requires input buffers with pts timestamp.
A debug trace is added to inform if pts mode is enabled and for
which codec.
Signed-off-by: Rafaël Carré <funman@videolan.org>

Ronald Wright has now answered. Check for details:
http://git.videolan.org/?p=vlc.git;a=commit;h=fef270581f736d4f6289a77cb115195241ed691d

Putting it between the libvlc_media_subitems comment and the function
definition messes parsing by doxygen and by the python module generator.

This is obnoxiously complicated. If anyone cares about playing_changed or
meta_changed, something similar will probably have to be done.

This is a pretty bizarre two-step system to inform the extension manager
that the input has changed, but it's necessary to avoid a series of
possible deadlocks and other issues. Here are other possible approaches
that don't work:

- Just call into the extension manager in -PlaylistItemChanged on the
main thread. This can pretty easily cause a deadlock if we call
-PlaylistItemChanged twice in quick succession. The first call will poke
the condvar the extension is waiting on, causing the extension thread to
wake up and run extension code; many parts of it -- including the dialog
code -- must be run on the main thread. The extension thread goes back to
sleep while blocking on the main thread to become available, while
holding the extension lock. Meanwhile the main thread goes into the
second call of -PlaylistItemChanged, attempts to lock the extension, and
that's a deadlock.

- Restructure the dialog manager to never block on the main thread while
holding the extension lock. This should work, but as it turns out doesn't
because the main thread will attempt to lock the same lock twice. What
happens is that -performSelectorOnMainThread works by injecting an event
into the main event loop of the main thread. For some unknown reason, as
part of its processing, when creating an NSAttributedString with HTML, it
runs the main event loop, which means we can end up executing one
-performSelectoOnMainThread as part of another. Since the dialog manager
uses attributed strings with HTML (since dialogs are HTML), we deadlock
here too. This seems strictly like a flaw in NSAttributedString and/or
in -performSelectorOnMainThread and is documented elsewhere:
  http://mrrsoftware.com/blog/tag/nsattributedstring/
  https://www.bluestatic.org/blog/2010/05/31/nsattributedstring-spins-a-nested-run-loop/

- Change around this bit of code to not force it to run on the main
thread. This would probably work, but, as a newcomer to VLC, I don't
quite know the implications of doing this, particularly since a lot of
code here seems to serailize on the main thread as a way of thread
safety; it would likely require some somewhat intricate restructuring
and adding of locks.

- Let the extension manager deal with listening for events the same way
that we do here. That would work, but would require duplicating a
nontrivial amount of code from here to deal with tracking the current
input.

- So, instead, we just serialized all calls to -PlaylistItemChanged (so
we make sure to process them in order, with no one trampling
p_input_changed), do most of the work on the main thread as before, and
then actually inform the extension manager out here where we don't block
the main thread. It seems likely that there are other pre-existing
deadlock possibilities here -- the main thread can't lock an extension!
-- but it at least tends to work in my testing.
Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>

Should fix #5906 in most cases

And update authors

Ref #7994

The following diff provides some fixes for VLC to allow building
with LLVM.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

This adds the SDP i= line (session information) as the description field
in the metadata of the SAP stream.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Close #4829

If the user has moved the extension dialog, we don't want to re-center it on every single update -- many extensions update their dialogs on every input change, and this behavior can cause the extension dialog to keep re-overlapping with the video, which is very frustrating.
Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>

Before it returned -1 when volume was set to 100% so OSD never showed the
'Volume: 100%' message.

Regards,
Mario
Signed-off-by: Rafaël Carré <funman@videolan.org>

Check that frame_rate_index is within bounds before dereferencing
the dirac_frate_tbl[] array.
Signed-off-by: Rafaël Carré <funman@videolan.org>

This reverts commit cec6c32f.

Avoid passing a structure on the stack.

For some filters, module's values may differ from the range shown to
users.