fluendo smd plugins for Intel smd platform

[Johns Victor]

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=technicolor.com at lists.freedesktop.org [mailto:gstreamer-devel-bounces+victor.johns=technicolor.com at lists.freedesktop.org] 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<wim.taymans at gmail.com>  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.

>> 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<msmith at xiph.org>    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
>>>> <Victor.Johns at technicolor.com>    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
>>>>> gstreamer-devel at lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>
>>>>>
>>>> _______________________________________________
>>>> gstreamer-devel mailing list
>>>> gstreamer-devel at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>
>>>
>>>
>>

_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel