[vlc-devel] libvlc_video_take_snapshot doesn't release lock on snapshot file?

[basos g]

2009/3/1 Rémi Denis-Courmont <rem at videolan.org>:
> 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.

Sorry, i didn't mean input thread. I was really thinking of interface
thread or libvlc user thread.

E.g. she who wants a snapshot would bear the burden. Interface thread
when user preses take snapshot from menu or hotkey and the libvlc user
thread (from another program) when user calls libvlc_take_snapshot.

For this i propose the work to be done on the take Snapshot Callback
that is eventually called with either way. Icould implement this by
calling vout_Snapshot from the callback function with a new cached
vout->p->p_picure_rendered. This would be the last rendered picture.
This has the disanvantage of permantly reserving another picture on
the heap but is it fairly simple to implement.

Onother elegant solution would be to leave the callback set a boolean
and then vout loop just push the current picture to be snaped on a
picture fifo. The problem here is who would own the fifo and manage
snapshot taking ? I don't know of any thread that is relaxed enough
for this and is always present. \
Input is time critical and always present.  Interface is relaxed but
not always present (e.g. on libvlc applications)

So i propose the first sol.
What you think ?