[vlc-devel] [PATCH] VOUT FIX snapshot lock, add new debug msgs

[basos g]

2009/3/8 Laurent Aimar <fenrir at via.ecp.fr>:
> Hi,
>
> On Sat, Mar 07, 2009, basos g wrote:
>> Now there is a modification to a vout variable whithout locking.
>> Of course with the current impl there no thing like snapshot queue
>> (for not to miss a snapshot ) .
>>
>> But this issue, as we have discussed before, should be totally
>> addressed by a redesign of the snapshot code.
>  I have changed the snapshot code to:
>  - not loose any request.
>  - encode in the caller iof the vout thread.
>  - be thread safe.
>
> So all the issue should be fixed now.
>
> Thanks for your work.

>


Excellent work ! This lightens vout from an asynchronous (heave) task
that could cause some timing problems. And it does not miss a snap!

A remark (and a patch that solves it). I tried, in the past, to make
the snapshot filename string as short as possible but with as much
info as possible. Hence the concatenated string %y%m%d-%H%M%S. As you
have changed it and is bigger i propose a solution without changing
the existing default: snapshot-strftime libvlc option is exported as
an adnvanced option for  the users to optionaly change the strftime
format string.

Also the patch fixes the i_id 1/10 of sec sequence number to be one
digit (insted of 3 digits). This enables snapshots to be taken with
min period 100 msecs.

PS: Another question i have, is vlc_cond_signal using a queue ? I mean
when i signal 5 times while the encoding thread is not
vlc_conf_timedwait(ing) yet, is it guaranteed that corresponding
vlc_cond_timedwait will be signaled 5 times when the right time comes
?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0017-Vout-Snapshot-Add-snapshot-strftime-libvlc-parame.patch
Type: text/x-diff
Size: 4297 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20090310/716befa1/attachment.patch>