GnlComposition Signals

[Edward Hervey]

On Mon, 2011-02-28 at 09:21 +0100, Angel Martin wrote:
> Dear all,
> 
> I have the next problem. 
> 
> When 3 contents are played and afterwards only 1 is performed using
> gnlcomposition an error appears, but if i remove one by one it works: 
> Content A start 0 dur 10 
> Content B start 0 dur 10 
> Content C start 0 dur 10 
> Content D start 10 dur 10 
> -> Seek Error 
> ERROR         gnlcomposition
> gnlcomposition.c:1724:no_more_pads_object_cb:<video-composition>
> Sending seek event failed! 

  You're not giving enough information. What priorities are you using ?
Do you have any other object apart from those 4 ?

> 
> Content A start 0 dur 10 
> Content B start 0 dur 9 
> Content C start 0 dur 8 
> Content D start 10 dur 10 
> -> Ok! 
> 
> In my case I have a gnloperation that places each content through the
> xpos, ypos and zorder attributes of the sinkpad of the videomixer. 
> 
> gnloperation = gst_element_factory_make ("gnloperation",
> "general-video-composition"); 
> videomixer = gst_element_factory_make ("videomixer",
> "general-video-adder"); 
> 
> gst_bin_add (GST_BIN (gnloperation), videomixer); 
> g_object_set(G_OBJECT (gnloperation), 
>     "expandable", TRUE, 
>     "priority", 0, 
>     NULL); 
> gst_bin_add (GST_BIN (gnlcomposition), gnloperation); 
> 
> g_signal_connect(gnloperation, "input-priority-changed", G_CALLBACK
> (onPriorityChange), data); 
> 
> In the onPriorityChange function I assign to each video/image content
> the xpos, ypos and zorder parameters mentioned before. 
> 
> So, as far as i understood it is supposed that the videomixer should
> manage properly the request_new_pad and release_request_pad calls, and
> no redefinition would be needed. 
> 
> However, depending on the number of performed contents the Seek Error
> appears or not.
> 
> After trying to understand the problem from the code of videomixer,
> gnlcomposition and gnloperation, I think that the problem could be the
> "gnloperation" element. 
> 
> In the code of of the function "synchronize_sinks" there is a call
> to: 
>     /* Remove pad */ 
>     /* FIXME, which one do we remove ? :) */ 
>     remove_sink_pad (operation, NULL); 
> 
> I think that this is the tricky point, because this function seems not
> be prepared to remove several sinks at once, so gstreamer try to seek
> a sinkpad that in fact doesn't have any source "connected". 
> 
> So a loop inside "synchronize_sinks" could fix it. 
>     /* Find unlinked sinkpads */ 
>     GstPad * sinkpad; 
>     while ((sinkpad = get_unlinked_sink_ghost_pad (operation)) !=
> NULL) { 
>        remove_sink_pad (operation, sinkpad); 
>     } 

  Fixed that in a pending branch, will try to push the commit later
today.

> 
> According to the GST_DEBUG log I think that the function
> "synchronize_sinks" is not called for each multimedia content removed
> by the composition, but once, so this code could fix it. 
> 
> But, again the Content D try to find a videomixer sink pad and it
> can't be found, so the pipeline freezes.
> 
> Could someone provide any idea to fix this situation?
> 
> Thank you in advance. 
> 
> Best Regards, 
> 
> Angel 
> 
> -- 
> Ángel Martín Navas
> Investigador / Researcher
> Televisión Digital y Servicios Multimedia / Digital TV & Multimedia Services
> 
> Vicomtech - Visual Interaction Communication Technologies
> 
> Mikeletegi Pasealekua, 57 - Parque Tecnológico
> 20009 Donostia - San Sebastián - Spain
> Tel: +[34] 943 30 92 30
> Fax: +[34] 943 30 93 93
> e-mail: amartin at vicomtech.org
> 
> www.vicomtech.org
> 
> *** member of IK4 Research Alliance ****
> www.ik4.es
> *** member of GraphicsMedia.net ****
> 
> www.graphicsmedia.net
> 
> 
> 
> -----------------------------------------------------
> Vicomtech is an ISO 9001:2000 certified institute
> -----------------------------------------------------
> 
> 
> Este mensaje se dirige exclusivamente a su destinatario. 
> La información incluida en el presente correo es confidencial sometida a 
> secreto profesional, especialmente en lo que respecta a los datos de 
> carácter personal, cuya divulgación está prohibida, en virtud de la 
> 
> legislación vigente. Si usted no es el destinatario legítimo y lo ha 
> recibido por error o tiene conocimiento del mismo por cualquier motivo, 
> le rogamos que nos lo comunique por este medio y proceda a destruirlo o 
> 
> borrarlo. En todo caso abstengase de utilizar, reproducir, alterar, 
> archivar o comunicar a terceros el presente mensaje así como los ficheros 
> anexos, todo ello bajo pena de incurrir en responsabilidades legales. 
> 
> Cualquier opinión contenida en este correo es exclusiva de su autor y no 
> representa necesariamente la opinión de ASOCIACIÓN CENTRO DE TECNOLOGÍAS 
> DE INTERACCIÓN VISUAL Y COMUNICACIONES VICOMTECH (en adelante Vicomtech-IK4) 
> 
> El emisor no garantiza la integridad, rapidez o seguridad del presente correo, 
> ni se responsabiliza de posibles perjuicios derivados de la captura, 
> incorporaciones de virus o cualesquiera otras manipulaciones efectuadas por terceros.
> 
> Con motivo de la entrada en vigor de la Ley 34/2002, de 11 de julio, de 
> Servicios de la Sociedad de la Información y de Comercio Electrónico, le 
> informamos que pueden revocar en cualquier momento, de forma sencilla y gratuita, 
> 
> el consentimiento para la recepción de mensajes de vicomtech.org en info.lopd at vicomtech.org.
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel