[vlc-devel] libvlc_video_take_snapshot doesn't release lock on snapshot file?
Rémi Denis-Courmont
rem at videolan.org
Sun Mar 1 16:53:44 CET 2009
Le dimanche 1 mars 2009 17:33:28 basos g, vous avez écrit :
> But the main concept is to keep render latency low. On this base i
> think snapshot taking code should run on another thread.
Yes.
> I propose input thread.
I'm afraid the input thread has the same problem as the vout thread. Both of
them are on the hot path for data. And the input thread is already
sufficiently complicated. In fact, I still get a busy loop when watching
DVDs, every so often.
> That would not put *asynchronous* snapshot burden on the vout loop( which ,
> with the current impementation, is very sensitive to latency issues) and
> could become more problematic when taking many snapshots. Some "late picture
> skipped" messages are common after a snapshot is taken.
Some of the vout stuff could be offloaded the vout thread completely with more
clever synchronization. Then we can do most of the vout changes
synchronously; indeed, I would much rather do that stuff from the
libvlc/hotkeys/interface threads. That is to say, whichever thread emitted
the vout request. It would also make the API simpler.
At the other end, I would also like to remove vout_thread_t.pf_manage. Those
vouts that need management should rather create a thread of their own.
Generally speaking, I would love to remove user interaction and arbitrary
pinging from the vout thread. But that's easier said that done.
No matter how you look at it, you need some synchronization with the vout
thread. For instance, snapshot needs to hold a picture from the picture heap,
such that the decoder will not overwrite the buffer until the snapshot is
done.
--
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary
More information about the vlc-devel
mailing list