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
<[hidden email]>
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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Locked
