GnlComposition Signals
Locked
 
|
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! 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); } 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 _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
Administrator
|
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: [hidden email] > > 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 [hidden email]. > > _______________________________________________ > 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 |
|
|
Dear Edward,
2011/2/28 Edward Hervey <[hidden email]>
My application is in someway a pitivi app but with transitions based on operations and concurrent image and video contents, I mean xpos and ypos parameters management from videomixer sinkpads to achieve overlapped multimedia. In my case A, B and C are imagefreezed images and after a video is played Videomixer that places xpos, ypos and zorder has Priority 0 The Content A has Priority 2 The Content B has Priority 3 The Content C has Priority 4 The Content D has Priority 5 Do you have any other object apart from those 4 ? Yes, I have another gnlcomposition that has a single mp3 file performed through all the A, B, C and D image/video contents, but I am quite sure that I have isolated the problem. Anyway, as far as I understood I think that, according to the GST_DEBUG logs, the problem could be in gnloperation, because it does not remove all the sink pads of the videomixer (only 1) and gstreamer try to perform a seek event over a sink pad that in fact I doesn't have anything connected. However, when all the sink pads of the videomixer are removed, by a modified gnloperation synchronize_sinks function, the content D is never played, because all the sinkpads have been removed and there is no unlinked sinkpad to be assigned to the content D. So at least one of the sinkpads of the video mixer should not be removed (operation->realsinks >=1??).
Ok! great news!
Thank you for your quick reply. Best, Angel _______________________________________________ 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 |