[
http://dev.sourcefabric.org/browse/LS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16436#action_16436
]
David Baelde commented on LS-439:
---------------------------------
Mmm, I had misunderstood the changes and made an erroneous comment is
yesterday's commit closing LS-365. The gstreamer/v4l does not rely on IORing,
but still on its own mechanism. This is okay with me, since it seems motivated
by a particular strategy for dealing with synchronization, silently dropping
and duplicating frames.
However, the operator remains broken in my opinion because it doesn't free the
resources it allocates. True, stopping the polling thread in #sleep doesn't
make sense if that thread is started in an initializer, but the real problem
here is that the thread is started in the initializer. This means that
source.shutdown can't work with the I/O like it does for others. While the
inputs could be enhanced easily, I'm still fine closing this ticket since a
fully perfect solution is too far away: our gstreamer ocaml binding doesn't
have deallocation functions anyway (so we could stop the thread but not
deallocate the sinks & stuff).
Given all that, wouldn't it make sense to flag input.v4l* as experimental?
> Failures / sleeps in v4l plugin
> -------------------------------
>
> Key: LS-439
> URL: http://dev.sourcefabric.org/browse/LS-439
> Project: Liquidsoap
> Issue Type: Technical task
> Components: Liquidsoap
> Reporter: Samuel Mimram
> Assignee: Romain Beauxis
> Priority: Blocker
> Fix For: 1.0
>
>
> We should make input.v4l faillible (it can fail when the webcam is not
> available or unplugged).
> Moreover, we should maybe also address this comment by David :
> "When they are turned off (#sleep) operators should free resources that they
> have allocated. Now that this operator allocates a thread, it should make
> sure the thread exits when the operator exits - it's also important in order
> to avoid having two polling threads if the operator is re-initialized. This
> can be done synchronously or not. We have similar problems with several other
> operators, and quite a bit of duplicated and clumsy code, which we should
> factorize and cleanup at some point."
> I am not sure that it really applies here though: the thread is created when
> the object for the operator is created (not when the operator is
> initialized). The polling thread is blocked on a condition which is signaled
> in get_frame: when the operator is sleeping, the thread simply gets blocked
> on the condition so it's not such a big problem...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://dev.sourcefabric.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Savonet-devl mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-devl
