Pierre Ynard [Thu, 28 Jan 2010 00:59:43 +0000 (01:59 +0100)]
rtp sout: fix another race condition in RTSP
When RTSP is shut down, the server destroys sessions (with no locking)
while clients are still able to concurrently access them, potentially
leading to a crash. Make sure we unregister the RTSP URL before
cleaning up (then indeed no locking is needed).
Pierre Ynard [Wed, 27 Jan 2010 23:55:00 +0000 (00:55 +0100)]
rtp sout: fix race condition in RTSP
When an ES is removed, it is possible to set up a track that won't be
cleaned up and will remain dangling, causing a crash later. Make sure
we unregister the RTSP URL before cleaning up.
Erwan Tulou [Wed, 27 Jan 2010 22:08:38 +0000 (23:08 +0100)]
Win32: correct the 'one-instance' deallocation code
'one-instance' happens to work on Win32 though there are several issues:
- a WM_QUIT is sent to the helper thread when any instance terminates
(the master or a secondary instance). 'one-instance' should then stop
working as soon as the first secondary instance terminates.
- But, sending WM_QUIT via SendMessage directly calls the window
procedure callback. And this callback here doesn't process the message
at all. Therefore, it is a no-op and the thread is actually never stopped.
This patch does the following :
- move the WM_QUIT message to ensure that only the master (first) instance
stops the helper thread.
- process the WM_QUIT message in the window procedure callback, and call
for clean termination of the thread.
Note that PostQuitMessage cannot be directly called as there are two
distincts threads here.
Laurent Aimar [Tue, 26 Jan 2010 22:34:02 +0000 (23:34 +0100)]
Redirected "zoom" on "scale" (vout_thread_t).
It fixes zoom settings at the core level (partially close #3245).
"zoom" cannot be removed as it provides a list of choices while "scale" is
a free value. The names aren't great, but that can wait.
Erwan Tulou [Tue, 26 Jan 2010 21:34:06 +0000 (22:34 +0100)]
freetype: fix a forgotten dialog progress bar when an error arises
With wine, this module goes through the error procedure, but forgets to
deallocate the progress bar (stuck to 80%).
This patch simply cleans it up so that vlc can still be used satisfactorily.
(an error message is also issued anyway)
André Weber [Tue, 26 Jan 2010 18:51:53 +0000 (19:51 +0100)]
Added AtmoLight tab inside video effects dialog
allows only to control some important options of the AtmoLight module, which control the color calculation.
Hardware setup has to be done inside the normal video filter setup.
André Weber [Tue, 26 Jan 2010 18:37:37 +0000 (19:37 +0100)]
enhanced & corrected AtmoLight filter module
- added more thread locking/synchronization, to avoid potential risk of race conditions
- changed the option to choose the output device
- added support for MoMoLight (http://www.ambilight4pc.com/momolight/momolight.html)
- added support for a simple serial DMX (255 channel) controller
- added support for Quattro Atmo Light (allows to use four separated classic AtmoLights, as one virtual AtmoLight)
- changed the way color packets are passed from AtmoExternalCaptureInput to AtmoLiveView useing a queue object (instead of a unsynchronized global variable)
- renamed some options inside atmo.cpp to meet the requirements from the video effect dialog widget (later commit)
- changed the way to define the zones for image color extraction (because the number of zones isn't longer fixed to 4 or 5)
- removed the need to copy some .dll as bridge for the external AtmoWin into the VideoLAN folder, try to load the dll from the same folder like AtmoWinX.exe
- do not a complete fade out, if the filter processed a low number of frames and gets stopped (keeps VideoLAN quick responding, if switching through deinterlacing modes)
- added a debug option to see which pixels are used for color computation (just for fun)
- added more infos to README.txt inside the source folder
Alexis Ballier [Mon, 25 Jan 2010 21:42:31 +0000 (22:42 +0100)]
Fix segfault when freetype-yuvp is set to 1 in vlcrc.
Allocate a palette for the format/region and reuse it. subpicture_region_Delete should take care of freeing it, but please someone double checks this to be sure.
Reported by: Alexander Stein
References: https://bugs.gentoo.org/show_bug.cgi?id=300406