[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