- 12 Jan, 2013 3 commits
-
-
Rémi Denis-Courmont authored
-
David Fuhrmann authored
- fix behavior of video-on-top by adapting to vout windows handling changes - set all windows to status level if one vout window has this level: This avoids that video effects panel, audio efffects panel etc. pp. are opened behind a vout window. Now they can be used as usual. Please note, that due to the type of these panels they do not remain visible when VLC gets inactive.
-
Devin Heitmueller authored
If we're using the new background renderer which just renders the background under the text (instead of the entire subpicture block), then don't call the legacy render as well. This prevents a alpha- transparent box from being shown when rendering EIA-608 captions if the user has the Freetype background opacity set to a nonzero value. Signed-off-by: Rafaël Carré <funman@videolan.org>
-
- 11 Jan, 2013 4 commits
-
-
Isamu Arimoto authored
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
-
Jean-Baptiste Kempf authored
-
Jean-Baptiste Kempf authored
(cherry picked from commit d6699a1f4ae27f04079edef946e2bf5a7fdb446b) Conflicts: po/fr.po
-
Denis Charmet authored
Avoid inifite loops and stack explosion when parsing broken files and ignore lvl 1 unknown elements. Fix #8013
-
- 10 Jan, 2013 9 commits
-
-
Rafaël Carré authored
That function was introduced years ago to account for bugs in aout, which do not exist anymore. Incidentally fix WMA.
-
Rafaël Carré authored
-
Rafaël Carré authored
-
Devin Heitmueller authored
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>
-
Rémi Denis-Courmont authored
-
Rafaël Carré authored
-
Hugues Fruchet authored
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>
-
Hugues Fruchet authored
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>
-
Jean-Baptiste Kempf authored
Ronald Wright has now answered. Check for details: http://git.videolan.org/?p=vlc.git;a=commit;h=fef270581f736d4f6289a77cb115195241ed691d
-
- 09 Jan, 2013 2 commits
-
-
Olivier Aubert authored
Putting it between the libvlc_media_subitems comment and the function definition messes parsing by doxygen and by the python module generator.
-
Jean-Baptiste Kempf authored
-
- 08 Jan, 2013 4 commits
-
-
Josh Watzman authored
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>
-
Francois Cartegnie authored
-
Jean-Baptiste Kempf authored
-
Rafaël Carré authored
-
- 07 Jan, 2013 10 commits
-
-
Rafaël Carré authored
-
Denis Charmet authored
Should fix #5906 in most cases
-
Rémi Denis-Courmont authored
-
Jean-Baptiste Kempf authored
And update authors
-
Jean-Baptiste Kempf authored
-
Jean-Baptiste Kempf authored
Ref #7994
-
Brad Smith authored
The following diff provides some fixes for VLC to allow building with LLVM. Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
-
Tillmann Karras authored
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>
-
Jean-Baptiste Kempf authored
-
Jean-Baptiste Kempf authored
Close #4829
-
- 06 Jan, 2013 5 commits
-
-
Rémi Denis-Courmont authored
-
Josh Watzman authored
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>
-
Rémi Duraffort authored
-
Mario Speiß authored
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>
-
Nickolai Zeldovich authored
Check that frame_rate_index is within bounds before dereferencing the dirac_frate_tbl[] array. Signed-off-by: Rafaël Carré <funman@videolan.org>
-
- 05 Jan, 2013 2 commits
-
-
Francois Cartegnie authored
-
Rémi Denis-Courmont authored
This reverts commit cec6c32f.
-
- 04 Jan, 2013 1 commit
-
-
David Fuhrmann authored
-