[vlc-devel] AtmoLight Threading Problem on linux

Andre Weber WeberAndre at gmx.de
Fri Dec 28 21:02:56 CET 2007


xtophe advised me to send my code to the mailing list, because I'am not able to get it really
to work without lockups after several 100 frames of processing, and without my kludge
of destroying and recreating the condition variable.

The zip contains my complete video_filter module - and my modules.am file, it is
required to compile the module with g++.

atmo.cpp is the mainfile containing all methods and functions directly interfacing into
vlc core.
the function: "AtmoInitialize" -- launches the MainThread (CAtmoLiveView) which computes the
"real light output" this thread is implemented inside "AtmoLiveView.cpp"  as subclass
of CThread which is implemented inside "AtmoThread.cpp" using VLC functions.
I did it this way, because the same code is also compiled into an Application only
running on Windows.

The thread CAtmoLiveView uses as helper for async preprocessing of the data
the thread inside "AtmoExternalCaptureInput.cpp" his job is it to convert the incoming
pixeldata into RGB values for each side of the picture - by an histogram and some
statistics. The most time this thread sleeps and will only woke up when new
pixeldata arrives through the method "DeliverNewSourceDataPaket" - which is
called from the source inside atmo.cpp.

How it Works ?

Atmo.Cpp: Filter( .. ) --> Atmo.Cpp:CreateMiniImage( .. ) --> Atmo.Cpp:AtmoSendPixelData( ... )
AtmoSendPixelData - decides on win32 only who gets the pixel data - my external application
or the "buildindriver" - on linux there is only the choice buildindriver.

Atmo.Cpp:AtmoSendPixelData( ... ) --> AtmoExternalCaptureInput.cpp: DeliverNewSourceDataPaket( ... )
(this wakes up the thread and processes the data) I did this in an extra thread to not slow down the playback
of the video, because this processing takes some ms.  If the data is processed the result is stored
in a variable of this class instance - than the thread goes sleeping until the next Paket arrives.

the output Thread "CAtmoLiveView" (in AtmoLiveView.cpp) get access to this values through
the method GetColorPacket() - which is done every 40ms to get an constant update rate of 25 HZ.
(the synchronization between these to threads and the real video is restored every 100 frames -
 with the method WaitForNextFrame( .. ))

The CAtmoLiveView Thread (Execute) is my biggest problem, this thread sleeps in
the end of its loop with CThread::ThreadSleep( ...) (from AtmoThread.cpp) --
this sleep could be interrupted by setting the termination condition for this thread
(CThread::Terminate()) - but as normal the sleep should timeout and then
continue the loop, but it happens very often at my site that this sleep never returns...
after the timeout...
(the same effect also happens to the CAtmoExternalCaptureInput::Execute method
where I directly used the vlc_cond_timedwait method)

to test the code it is required to configure the module inside the extended settings
and give him an free and unused serial port its not required that there is anything
connected to this serial port.

Thanks everybody which helps me... in any way.... suggestions are welcome...


for reading the code only code inside the define "_ATMO_VLC_PLUGIN_"
are used for the VLC module. The define "_ATMO_KLUDGE_" enabled
my current workaround - which destroys / recreates the conditionvariable
some times...

My Environment:
svn  vlc-trunk (current) 0.9er
on ubuntu feisty
-------------- next part --------------
A non-text attachment was scrubbed...
Name: atmo1.zip
Type: application/x-zip-compressed
Size: 54198 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20071228/73406abb/attachment.bin>

More information about the vlc-devel mailing list