fluendo smd plugins for Intel smd platform
Locked
fluendo smd plugins for Intel smd platform
 
|
Hi All,
I am going
thru the fluendo smd plugins and currently am trying to understand how the clock
distribution works. Typically in the smd platform, there will be a single clock
that drives all the renderers, in this way all the renderers can have the same
base time. As I go thru the code, I see that each renderer will allocate a
clock, which is kind of strange. I also noticed in the ismd_plugins.c file that
the ismd_gst_clock element was not initialized. When I add this to the
static struct _elements_entry _elements[] array, i get an error thatgst-plugin-scanner:688: Glib-CRITICAL g_once_init_leave: assertion initialization_valye != 0 failed gst-plugin-scanner:688 GStreamer-CRITICAL : gst_element_regiser : assertion `g_type_is_a (type, GST_TYPE_ELEMENT) failed
So I don't think that this code is meant to be part of a gst-launch pipeline. If this is the case, I don't see how all the smd renderers can be synced to the same master clock.
Any input appreciated
Regards
Victor
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: fluendo smd plugins for Intel smd platform
|
|
You should probably contact fluendo's technical support for assistance
with their custom plugins. We're happy to help out with general gstreamer questions here - but we can't help you with details of one particular vendor's proprietary plugins. Mike On Wed, Feb 23, 2011 at 9:37 AM, Johns Victor <[hidden email]> wrote: > Hi All, > I am going thru the fluendo smd plugins and currently am trying to > understand how the clock distribution works. Typically in the smd platform, > there will be a single clock that drives all the renderers, in this way all > the renderers can have the same base time. As I go thru the code, I see that > each renderer will allocate a clock, which is kind of strange. I also > noticed in the ismd_plugins.c file that the ismd_gst_clock element was not > initialized. When I add this to the > > static > > struct _elements_entry _elements[] array, i get an error that > > gst-plugin-scanner:688: Glib-CRITICAL g_once_init_leave: assertion > initialization_valye != 0 failed > > gst-plugin-scanner:688 GStreamer-CRITICAL : gst_element_regiser : assertion > `g_type_is_a (type, GST_TYPE_ELEMENT) failed > > > > So I don't think that this code is meant to be part of a gst-launch > pipeline. If this is the case, I don't see how all the smd renderers can be > synced to the same master clock. > > > > Any input appreciated > > > > Regards > > > > Victor > > > > > > > > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: fluendo smd plugins for Intel smd platform
|
|
Hi,
The source code for the plugins is actually available under an LGPL license [1], although you cannot build them without Intel's SDK. I have a more general question related to these plugins: in Gstreamer the clock chosen for the pipeline is the one provided by the most upstream element that provides a clock. For example for an RTSP source, the clock would be provided by the rtp bin. The elements in the fluendo plugins (mpegts demux, video and audio renderer) require a hardware clock, that they provide. However it won't be used, instead the software rtp clock will be used, which will not allow the hw elements to work. Is there any way to prevent the rtp clock to be selected ? Thanks [1] http://core.fluendo.com/gstreamer/src/gst-fluendo-ismd/ PS: Good luck Victor to finish your orange box ! On Wed, Feb 23, 2011 at 6:59 PM, Michael Smith <[hidden email]> wrote: > You should probably contact fluendo's technical support for assistance > with their custom plugins. > > We're happy to help out with general gstreamer questions here - but we > can't help you with details of one particular vendor's proprietary > plugins. > > Mike > > > On Wed, Feb 23, 2011 at 9:37 AM, Johns Victor > <[hidden email]> wrote: >> Hi All, >> I am going thru the fluendo smd plugins and currently am trying to >> understand how the clock distribution works. Typically in the smd platform, >> there will be a single clock that drives all the renderers, in this way all >> the renderers can have the same base time. As I go thru the code, I see that >> each renderer will allocate a clock, which is kind of strange. I also >> noticed in the ismd_plugins.c file that the ismd_gst_clock element was not >> initialized. When I add this to the >> >> static >> >> struct _elements_entry _elements[] array, i get an error that >> >> gst-plugin-scanner:688: Glib-CRITICAL g_once_init_leave: assertion >> initialization_valye != 0 failed >> >> gst-plugin-scanner:688 GStreamer-CRITICAL : gst_element_regiser : assertion >> `g_type_is_a (type, GST_TYPE_ELEMENT) failed >> >> >> >> So I don't think that this code is meant to be part of a gst-launch >> pipeline. If this is the case, I don't see how all the smd renderers can be >> synced to the same master clock. >> >> >> >> Any input appreciated >> >> >> >> Regards >> >> >> >> Victor >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> gstreamer-devel mailing list >> [hidden email] >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >> >> > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > -- Arnaud Vrac _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: fluendo smd plugins for Intel smd platform
|
|
On 02/24/2011 01:47 AM, Arnaud Vrac wrote:
> Hi, > > The source code for the plugins is actually available under an LGPL > license [1], although you cannot build them without Intel's SDK. > > I have a more general question related to these plugins: in Gstreamer > the clock chosen for the pipeline is the one provided by the most > upstream element that provides a clock. For example for an RTSP > source, the clock would be provided by the rtp bin. The elements in > the fluendo plugins (mpegts demux, video and audio renderer) require a > hardware clock, that they provide. However it won't be used, instead > the software rtp clock will be used, which will not allow the hw > elements to work. Is there any way to prevent the rtp clock to be > selected ? > You can use gst_pipeline_use_clock() to bypass the clock selection and force the use of a particular clock. Better is to fix the elements so that they can work with any clock. Wim > Thanks > > [1] http://core.fluendo.com/gstreamer/src/gst-fluendo-ismd/ > > PS: Good luck Victor to finish your orange box ! > > On Wed, Feb 23, 2011 at 6:59 PM, Michael Smith<[hidden email]> wrote: >> You should probably contact fluendo's technical support for assistance >> with their custom plugins. >> >> We're happy to help out with general gstreamer questions here - but we >> can't help you with details of one particular vendor's proprietary >> plugins. >> >> Mike >> >> >> On Wed, Feb 23, 2011 at 9:37 AM, Johns Victor >> <[hidden email]> wrote: >>> Hi All, >>> I am going thru the fluendo smd plugins and currently am trying to >>> understand how the clock distribution works. Typically in the smd platform, >>> there will be a single clock that drives all the renderers, in this way all >>> the renderers can have the same base time. As I go thru the code, I see that >>> each renderer will allocate a clock, which is kind of strange. I also >>> noticed in the ismd_plugins.c file that the ismd_gst_clock element was not >>> initialized. When I add this to the >>> >>> static >>> >>> struct _elements_entry _elements[] array, i get an error that >>> >>> gst-plugin-scanner:688: Glib-CRITICAL g_once_init_leave: assertion >>> initialization_valye != 0 failed >>> >>> gst-plugin-scanner:688 GStreamer-CRITICAL : gst_element_regiser : assertion >>> `g_type_is_a (type, GST_TYPE_ELEMENT) failed >>> >>> >>> >>> So I don't think that this code is meant to be part of a gst-launch >>> pipeline. If this is the case, I don't see how all the smd renderers can be >>> synced to the same master clock. >>> >>> >>> >>> Any input appreciated >>> >>> >>> >>> Regards >>> >>> >>> >>> Victor >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> gstreamer-devel mailing list >>> [hidden email] >>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >>> >>> >> _______________________________________________ >> gstreamer-devel mailing list >> [hidden email] >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >> > > > _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: fluendo smd plugins for Intel smd platform
|
|
On Thu, Feb 24, 2011 at 8:34 AM, Wim Taymans <[hidden email]> wrote:
> On 02/24/2011 01:47 AM, Arnaud Vrac wrote: >> >> Hi, >> >> The source code for the plugins is actually available under an LGPL >> license [1], although you cannot build them without Intel's SDK. >> >> I have a more general question related to these plugins: in Gstreamer >> the clock chosen for the pipeline is the one provided by the most >> upstream element that provides a clock. For example for an RTSP >> source, the clock would be provided by the rtp bin. The elements in >> the fluendo plugins (mpegts demux, video and audio renderer) require a >> hardware clock, that they provide. However it won't be used, instead >> the software rtp clock will be used, which will not allow the hw >> elements to work. Is there any way to prevent the rtp clock to be >> selected ? >> > > You can use gst_pipeline_use_clock() to bypass the clock selection and force > the use of a particular clock. Better is to fix the elements so that they > can work with any clock. Ok thanks Wim. Unfortunately it's not possible to use a software clock unless Intel rewrites a lot of the driver code. > > Wim > >> Thanks >> >> [1] http://core.fluendo.com/gstreamer/src/gst-fluendo-ismd/ >> >> PS: Good luck Victor to finish your orange box ! >> >> On Wed, Feb 23, 2011 at 6:59 PM, Michael Smith<[hidden email]> wrote: >>> >>> You should probably contact fluendo's technical support for assistance >>> with their custom plugins. >>> >>> We're happy to help out with general gstreamer questions here - but we >>> can't help you with details of one particular vendor's proprietary >>> plugins. >>> >>> Mike >>> >>> >>> On Wed, Feb 23, 2011 at 9:37 AM, Johns Victor >>> <[hidden email]> wrote: >>>> >>>> Hi All, >>>> I am going thru the fluendo smd plugins and currently am trying to >>>> understand how the clock distribution works. Typically in the smd >>>> platform, >>>> there will be a single clock that drives all the renderers, in this way >>>> all >>>> the renderers can have the same base time. As I go thru the code, I see >>>> that >>>> each renderer will allocate a clock, which is kind of strange. I also >>>> noticed in the ismd_plugins.c file that the ismd_gst_clock element was >>>> not >>>> initialized. When I add this to the >>>> >>>> static >>>> >>>> struct _elements_entry _elements[] array, i get an error that >>>> >>>> gst-plugin-scanner:688: Glib-CRITICAL g_once_init_leave: assertion >>>> initialization_valye != 0 failed >>>> >>>> gst-plugin-scanner:688 GStreamer-CRITICAL : gst_element_regiser : >>>> assertion >>>> `g_type_is_a (type, GST_TYPE_ELEMENT) failed >>>> >>>> >>>> >>>> So I don't think that this code is meant to be part of a gst-launch >>>> pipeline. If this is the case, I don't see how all the smd renderers can >>>> be >>>> synced to the same master clock. >>>> >>>> >>>> >>>> Any input appreciated >>>> >>>> >>>> >>>> Regards >>>> >>>> >>>> >>>> Victor >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> gstreamer-devel mailing list >>>> [hidden email] >>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >>>> >>>> >>> _______________________________________________ >>> gstreamer-devel mailing list >>> [hidden email] >>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >>> >> >> >> > > -- Arnaud Vrac _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: fluendo smd plugins for Intel smd platform
|
|
Hi Arnaud,
Another option is to have a modified RTP src element exporting a clock using the Intel SMD clock and adjusting it with the network timing information. For IPTV streams we made a clock provider element that does this using the MPEG TS clocking information just after udpsrc.
Best regards,
Julien Moutte www.fluendo.com & www.moovida.com P Please consider the environment before printing this e-mail. On Thu, Feb 24, 2011 at 10:15 AM, Arnaud Vrac <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: fluendo smd plugins for Intel smd platform
|
|
In reply to this post by Arnaud Vrac
On 02/24/2011 10:15 AM, Arnaud Vrac wrote:
> On Thu, Feb 24, 2011 at 8:34 AM, Wim Taymans<[hidden email]> wrote: >> On 02/24/2011 01:47 AM, Arnaud Vrac wrote: >>> Hi, >>> >>> The source code for the plugins is actually available under an LGPL >>> license [1], although you cannot build them without Intel's SDK. >>> >>> I have a more general question related to these plugins: in Gstreamer >>> the clock chosen for the pipeline is the one provided by the most >>> upstream element that provides a clock. For example for an RTSP >>> source, the clock would be provided by the rtp bin. The elements in >>> the fluendo plugins (mpegts demux, video and audio renderer) require a >>> hardware clock, that they provide. However it won't be used, instead >>> the software rtp clock will be used, which will not allow the hw >>> elements to work. Is there any way to prevent the rtp clock to be >>> selected ? >>> >> You can use gst_pipeline_use_clock() to bypass the clock selection and force >> the use of a particular clock. Better is to fix the elements so that they >> can work with any clock. > Ok thanks Wim. Unfortunately it's not possible to use a software clock > unless Intel rewrites a lot of the driver code. > gstreamer level. >> Wim >> >>> Thanks >>> >>> [1] http://core.fluendo.com/gstreamer/src/gst-fluendo-ismd/ >>> >>> PS: Good luck Victor to finish your orange box ! >>> >>> On Wed, Feb 23, 2011 at 6:59 PM, Michael Smith<[hidden email]> wrote: >>>> You should probably contact fluendo's technical support for assistance >>>> with their custom plugins. >>>> >>>> We're happy to help out with general gstreamer questions here - but we >>>> can't help you with details of one particular vendor's proprietary >>>> plugins. >>>> >>>> Mike >>>> >>>> >>>> On Wed, Feb 23, 2011 at 9:37 AM, Johns Victor >>>> <[hidden email]> wrote: >>>>> Hi All, >>>>> I am going thru the fluendo smd plugins and currently am trying to >>>>> understand how the clock distribution works. Typically in the smd >>>>> platform, >>>>> there will be a single clock that drives all the renderers, in this way >>>>> all >>>>> the renderers can have the same base time. As I go thru the code, I see >>>>> that >>>>> each renderer will allocate a clock, which is kind of strange. I also >>>>> noticed in the ismd_plugins.c file that the ismd_gst_clock element was >>>>> not >>>>> initialized. When I add this to the >>>>> >>>>> static >>>>> >>>>> struct _elements_entry _elements[] array, i get an error that >>>>> >>>>> gst-plugin-scanner:688: Glib-CRITICAL g_once_init_leave: assertion >>>>> initialization_valye != 0 failed >>>>> >>>>> gst-plugin-scanner:688 GStreamer-CRITICAL : gst_element_regiser : >>>>> assertion >>>>> `g_type_is_a (type, GST_TYPE_ELEMENT) failed >>>>> >>>>> >>>>> >>>>> So I don't think that this code is meant to be part of a gst-launch >>>>> pipeline. If this is the case, I don't see how all the smd renderers can >>>>> be >>>>> synced to the same master clock. >>>>> >>>>> >>>>> >>>>> Any input appreciated >>>>> >>>>> >>>>> >>>>> Regards >>>>> >>>>> >>>>> >>>>> Victor >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> gstreamer-devel mailing list >>>>> [hidden email] >>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >>>>> >>>>> >>>> _______________________________________________ >>>> gstreamer-devel mailing list >>>> [hidden email] >>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >>>> >>> >>> >> _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
RE: fluendo smd plugins for Intel smd platform
|
|
Hi,
The approach that I was thinking of was to write an Intel based clock provider element that would provide a master clock to the pipeline. This seems to fall in line with the general gstreamer approach, but I was not sure if this was the right way to go. If this method is followed then effectively the clocks that are allocated in the sink elements can be deprecated is this a correct statement Regards Victor -----Original Message----- From: gstreamer-devel-bounces+victor.johns=[hidden email] [mailto:gstreamer-devel-bounces+victor.johns=[hidden email]] On Behalf Of Wim Taymans Sent: Thursday, February 24, 2011 4:33 AM To: Arnaud Vrac Cc: Discussion of the development of and with GStreamer Subject: Re: fluendo smd plugins for Intel smd platform On 02/24/2011 10:15 AM, Arnaud Vrac wrote: > On Thu, Feb 24, 2011 at 8:34 AM, Wim Taymans<[hidden email]> wrote: >> On 02/24/2011 01:47 AM, Arnaud Vrac wrote: >>> Hi, >>> >>> The source code for the plugins is actually available under an LGPL >>> license [1], although you cannot build them without Intel's SDK. >>> >>> I have a more general question related to these plugins: in >>> Gstreamer the clock chosen for the pipeline is the one provided by >>> the most upstream element that provides a clock. For example for an >>> RTSP source, the clock would be provided by the rtp bin. The >>> elements in the fluendo plugins (mpegts demux, video and audio >>> renderer) require a hardware clock, that they provide. However it >>> won't be used, instead the software rtp clock will be used, which >>> will not allow the hw elements to work. Is there any way to prevent >>> the rtp clock to be selected ? >>> >> You can use gst_pipeline_use_clock() to bypass the clock selection >> and force the use of a particular clock. Better is to fix the >> elements so that they can work with any clock. > Ok thanks Wim. Unfortunately it's not possible to use a software clock > unless Intel rewrites a lot of the driver code. > >> Wim >> >>> Thanks >>> >>> [1] http://core.fluendo.com/gstreamer/src/gst-fluendo-ismd/ >>> >>> PS: Good luck Victor to finish your orange box ! >>> >>> On Wed, Feb 23, 2011 at 6:59 PM, Michael Smith<[hidden email]> wrote: >>>> You should probably contact fluendo's technical support for >>>> assistance with their custom plugins. >>>> >>>> We're happy to help out with general gstreamer questions here - but >>>> we can't help you with details of one particular vendor's >>>> proprietary plugins. >>>> >>>> Mike >>>> >>>> >>>> On Wed, Feb 23, 2011 at 9:37 AM, Johns Victor >>>> <[hidden email]> wrote: >>>>> Hi All, >>>>> I am going thru the fluendo smd plugins and currently am trying >>>>> to understand how the clock distribution works. Typically in the >>>>> smd platform, there will be a single clock that drives all the >>>>> renderers, in this way all the renderers can have the same base >>>>> time. As I go thru the code, I see that each renderer will >>>>> allocate a clock, which is kind of strange. I also noticed in the >>>>> ismd_plugins.c file that the ismd_gst_clock element was not >>>>> initialized. When I add this to the >>>>> >>>>> static >>>>> >>>>> struct _elements_entry _elements[] array, i get an error that >>>>> >>>>> gst-plugin-scanner:688: Glib-CRITICAL g_once_init_leave: assertion >>>>> initialization_valye != 0 failed >>>>> >>>>> gst-plugin-scanner:688 GStreamer-CRITICAL : gst_element_regiser : >>>>> assertion >>>>> `g_type_is_a (type, GST_TYPE_ELEMENT) failed >>>>> >>>>> >>>>> >>>>> So I don't think that this code is meant to be part of a >>>>> gst-launch pipeline. If this is the case, I don't see how all the >>>>> smd renderers can be synced to the same master clock. >>>>> >>>>> >>>>> >>>>> Any input appreciated >>>>> >>>>> >>>>> >>>>> Regards >>>>> >>>>> >>>>> >>>>> Victor >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> gstreamer-devel mailing list >>>>> [hidden email] >>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >>>>> >>>>> >>>> _______________________________________________ >>>> gstreamer-devel mailing list >>>> [hidden email] >>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >>>> >>> >>> >> _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: fluendo smd plugins for Intel smd platform
|
|
On Thu, Feb 24, 2011 at 1:01 PM, Johns Victor
<[hidden email]> wrote: > Hi, > The approach that I was thinking of was to write an Intel based clock provider element that would provide a master clock to the pipeline. This seems to fall in line with the general gstreamer approach, but I was not sure if this was the right way to go. If this method is followed then effectively the clocks that are allocated in the sink elements can be deprecated is this a correct statement This is the approach Intel used in their deprecated gstreamer plugins, however this approach does not work with playbin for autoplugging. > > -----Original Message----- > From: gstreamer-devel-bounces+victor.johns=[hidden email] [mailto:gstreamer-devel-bounces+victor.johns=[hidden email]] On Behalf Of Wim Taymans > Sent: Thursday, February 24, 2011 4:33 AM > To: Arnaud Vrac > Cc: Discussion of the development of and with GStreamer > Subject: Re: fluendo smd plugins for Intel smd platform > > On 02/24/2011 10:15 AM, Arnaud Vrac wrote: >> On Thu, Feb 24, 2011 at 8:34 AM, Wim Taymans<[hidden email]> wrote: >>> On 02/24/2011 01:47 AM, Arnaud Vrac wrote: >>>> Hi, >>>> >>>> The source code for the plugins is actually available under an LGPL >>>> license [1], although you cannot build them without Intel's SDK. >>>> >>>> I have a more general question related to these plugins: in >>>> Gstreamer the clock chosen for the pipeline is the one provided by >>>> the most upstream element that provides a clock. For example for an >>>> RTSP source, the clock would be provided by the rtp bin. The >>>> elements in the fluendo plugins (mpegts demux, video and audio >>>> renderer) require a hardware clock, that they provide. However it >>>> won't be used, instead the software rtp clock will be used, which >>>> will not allow the hw elements to work. Is there any way to prevent >>>> the rtp clock to be selected ? >>>> >>> You can use gst_pipeline_use_clock() to bypass the clock selection >>> and force the use of a particular clock. Better is to fix the >>> elements so that they can work with any clock. >> Ok thanks Wim. Unfortunately it's not possible to use a software clock >> unless Intel rewrites a lot of the driver code. >> > There is no need to rewrite any driver code, you can fix this is at the gstreamer level. > Really ? Can you please elaborate, I don't see how do to that. Thanks >>> Wim >>> >>>> Thanks >>>> >>>> [1] http://core.fluendo.com/gstreamer/src/gst-fluendo-ismd/ >>>> >>>> PS: Good luck Victor to finish your orange box ! >>>> >>>> On Wed, Feb 23, 2011 at 6:59 PM, Michael Smith<[hidden email]> wrote: >>>>> You should probably contact fluendo's technical support for >>>>> assistance with their custom plugins. >>>>> >>>>> We're happy to help out with general gstreamer questions here - but >>>>> we can't help you with details of one particular vendor's >>>>> proprietary plugins. >>>>> >>>>> Mike >>>>> >>>>> >>>>> On Wed, Feb 23, 2011 at 9:37 AM, Johns Victor >>>>> <[hidden email]> wrote: >>>>>> Hi All, >>>>>> I am going thru the fluendo smd plugins and currently am trying >>>>>> to understand how the clock distribution works. Typically in the >>>>>> smd platform, there will be a single clock that drives all the >>>>>> renderers, in this way all the renderers can have the same base >>>>>> time. As I go thru the code, I see that each renderer will >>>>>> allocate a clock, which is kind of strange. I also noticed in the >>>>>> ismd_plugins.c file that the ismd_gst_clock element was not >>>>>> initialized. When I add this to the >>>>>> >>>>>> static >>>>>> >>>>>> struct _elements_entry _elements[] array, i get an error that >>>>>> >>>>>> gst-plugin-scanner:688: Glib-CRITICAL g_once_init_leave: assertion >>>>>> initialization_valye != 0 failed >>>>>> >>>>>> gst-plugin-scanner:688 GStreamer-CRITICAL : gst_element_regiser : >>>>>> assertion >>>>>> `g_type_is_a (type, GST_TYPE_ELEMENT) failed >>>>>> >>>>>> >>>>>> >>>>>> So I don't think that this code is meant to be part of a >>>>>> gst-launch pipeline. If this is the case, I don't see how all the >>>>>> smd renderers can be synced to the same master clock. >>>>>> >>>>>> >>>>>> >>>>>> Any input appreciated >>>>>> >>>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>> >>>>>> >>>>>> Victor >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> gstreamer-devel mailing list >>>>>> [hidden email] >>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> gstreamer-devel mailing list >>>>> [hidden email] >>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >>>>> >>>> >>>> >>> > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > -- Arnaud Vrac _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |