After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 115559 - Deadlock with video thread
Deadlock with video thread
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: dont know
git master
Other Linux
: Normal blocker
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2003-06-19 19:13 UTC by Stephan Haller
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gdb output of all processes (5.90 KB, text/plain)
2003-06-19 19:14 UTC, Stephan Haller
Details
Multiplexer source code derived from example plugin source code provided by gstreamer (18.55 KB, text/plain)
2003-06-20 17:25 UTC, Stephan Haller
Details
Debug logfile with source code containing loop-based multiplexer (218.11 KB, application/octet-stream)
2003-06-21 17:34 UTC, Stephan Haller
Details

Description Stephan Haller 2003-06-19 19:13:30 UTC
I'm using gstreamer to transcode a MPEG audio and video file to a propiate
file format for an old computer system.

I'm using the main pipeline and three thread. The (main) pipeline devileres
the mpegdemux element the datas. One thread is then doing the audio
decoding/encoding. The second thread is doing video
decoding/converting/encoding. The third and last thread is doing multiplexing.

The video thread seems to be totally broken (freezes) because if I disable
the video thread my app is running till the whole source file (mpeg
audio/video file is transcoded). But if I disable audio thread my whole app
is broken finding no parent elements anymore for example.

Attaching output from gdb (That are 5 processes)
Comment 1 Stephan Haller 2003-06-19 19:14:12 UTC
Created attachment 17634 [details]
gdb output of all processes
Comment 2 Ronald Bultje 2003-06-20 13:32:48 UTC
What pipeline are you using exactly? What elements?
Comment 3 Stephan Haller 2003-06-20 13:49:46 UTC
Normal pipeline created via gst_pipeline_new(...) with a filesrc and
mpegdemux element.

In first thread (called "video_thread") there are: video_input_queue
(queue), video_decoder (mpeg2dec), video_converter (colorspace),
video_encoder (my sam_video_encoder codec) and video_output queue.

The second thread (called "audio_thread") contains of:
audio_input_queue (queue), audio_decoder (mpeg2dec), audio_encoder (my
sam_audio_encoder codec) and audio_output queue.

The third and last thread has: muxer (my sam_multiplexer codec) and a
filesink.

That's all. I tried different schedulers but all stop completely
working after 0,19% up to 1,20% of 700MB transcoded. If I apply a
gst-mask=0x100 I get sometimes (really only sometime) that queues get
decoupled! 
Comment 4 Stephan Haller 2003-06-20 13:54:03 UTC
Forgot! The threads are in pipeline but I guess you guessed!
Comment 5 Ronald Bultje 2003-06-20 15:16:40 UTC
Yeah. ;).

Is the muxer chain-based or loop-based? Only loop-based elements are
supported for now.
Comment 6 Stephan Haller 2003-06-20 16:37:10 UTC
Show loop-based first. But pulling datas from the both output queue
resulted always in nothing. I got no datas to push them to the
filesink. After changing the muxer to a chain-based it got datas.
Comment 7 Ronald Bultje 2003-06-20 17:18:36 UTC
Then there's your problem, chain-based muxers don't work.

Loop-based should. Could you show some code? Loop-based works for me...
Comment 8 Stephan Haller 2003-06-20 17:25:48 UTC
Created attachment 17660 [details]
Multiplexer source code derived from example plugin source code provided by gstreamer
Comment 9 Stephan Haller 2003-06-21 17:34:18 UTC
Created attachment 17680 [details]
Debug logfile with source code containing loop-based multiplexer
Comment 10 Ronald Bultje 2003-06-30 21:44:01 UTC
This is working now, closing...