[ 
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]
_______________________________________________

Reply via email to