[
http://opencast.jira.com/browse/MH-7641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=26325#comment-26325
]
Christopher Brooks commented on MH-7641:
----------------------------------------
While this could be done the premises motivating the work are incorrect;
deinit() is never supposed to be called in a normal program:
<cab938> What does deinit() do?
<cab938> I've got a situation where I init gstreamer
<cab938> and then run a bunch of pipelines
<MikeS> cab938: some cleanup. It's useful in test cases to help test that
everything's cleaned up correctly. It should not be used in real programs
<cab938> ok, tyvm
<__tim> (see
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-Gst.html#gst-deinit)
<cab938> we just had a huge discussion about when to init and when to deinit
<MikeS> You can only initialise gstreamer once. You can't re-initialise it if
you ever deinit it.
<ami020> I can test it on tommarow morning in office
<cab938> and it was driving me nuts because I thought that init was important
but deinit was, in general, not neccessary
* anholt ([email protected]) has joined #gstreamer
<bilboed> cab938, you were right then :)
<cab938> Indeed
<bilboed> because you read the docs and the others didn't
<ami020> Mike on which area you think I have to focus on ?
<cab938> So the term "resources" though is a big vague, we're using several
pipelines with several live sources and file sources. I don't have to worry
about deinit() freeing up locks on these resources though right, like the
alsasrc?
<cab938> I can just eos/null these and go on
<bilboed> cab938, that's done on a element/plugin/object level
<cab938> yup, ok, as I figured
<bilboed> cab938, yah
<cab938> tyvm
<__tim> cab938, those kind of resources should be freed when you set the
pipeline to NULL state and unref it
<ami020> proble with audioflingersink?
<__tim> cab938, the kind of resources gst_deinit() is talking about is one-time
global allocations (type system etc.)
> Refactor all the Gstreamer-related code out of the capture agent and put it
> inside its own bundle
> -------------------------------------------------------------------------------------------------
>
> Key: MH-7641
> URL: http://opencast.jira.com/browse/MH-7641
> Project: Matterhorn Project
> Issue Type: Task
> Components: Capture (Devices and Software)
> Affects Versions: 1.2
> Reporter: Rubén Pérez Vázquez
> Assignee: Christopher Brooks
>
> (18:56:24) Rubencino: Imagine we've got a couple bundles that use gstreamer
> (18:56:34) Rubencino: and suposse that one of them finishes the work and
> calls deinit
> (18:57:07) Rubencino: if the other is currently doing something with
> gstreamer, it will probably crash
> (18:57:17) Rubencino: because the underlying framework is all the same
> (18:57:20) greg_logan: yup
> (18:57:22) jholtzman: I see... yes, we would not be able to call deinit there
> [...]
> I think it's a solution in search of a problem. We don't have enough code
> using gstreamer at the moment to make that kind of refactoring worth it.
> (19:12:23) greg_logan: maybe once we get confidence monitoring in and going
> again, but not yet
> (19:12:41) jholtzman: greg_logan: Rubencino The way to do this is, in my
> opinion, create an OSGI bundle that exports the gstreamer packages
> (19:12:54) jholtzman: rather than bundling gstreamer in the CA impl jar, as
> we do now
> (19:13:03) jholtzman: that jar can have a bundle activator
> (19:13:07) jholtzman: that calls init and deinit
> (19:13:20) jholtzman: so if the gstreamer packages are available, gstreamer's
> been init'ed
> (19:13:27) jholtzman: if they are not, it's been de-inited
> (19:13:32) jholtzman: ok, cool
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________