deadlock issue in pipeline

[marcin at saepia.net]

Hi,

my experience is that in most cases deadlock is caused by

a) calling set_state from thread other than application thread,
b) dynamically joining elements of playing pipeline and,
 i. using synchronous pad blocks or,
 ii. trying to join element that is not playing to already playing pipeline,
c) other weird things you've did manually with threading.

Call your application with GST_DEBUG=*:3 and seek for warnings/errors or
string "pausing after". Source of the error not necessarily will appear at
the end of the log as GStreamer can do a bit of processing before causing
source of deadlock and to moment in which deadlock actually happens.

m.



2012/7/23 Kaijun Tang <kaijun61 at yahoo.com>

> Hi,
>
> When an A/V stream is played in a pipeline, video and audio streams are
> passed downstream in separate branches. For the sake of sync. there are
> queue buffers between A/V codec and A/V sink. After A/V frames are
> pre-rolled, the sinks send message to the pipeline. When the pipeline
> receives both messages, A/V streams begin to play in terms of timestamp for
> sync. In case that one of branches is blocked, the pipeline would be
> deadlock. E.g. either audio buffers or video buffers are filled before one
> of A/V prerolls is reached. I met one case, there are many audio packets
> before the video packets come. I have to use a big buffer, In another case,
> video doesn't start from I frame, as a result, the audio buffers are
> quickly full. The audio branch blocks further incoming packets. Is there a
> better approach to oversome this issue?
>
>
> Kind Regards
>
> Kai
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20120723/8b9ab8f2/attachment.html>