GNOME Bugzilla – Bug 597883
Using playbin2 instead of playbin blocks the pipeline
Last modified: 2010-01-16 20:42:17 UTC
I have the content "making_of_elephants_dream_3160kbps_2chn_48000Hz.mpg" It starts rendering correctly when using this command: gst-launch playbin uri=file:///home/francis/Desktop /making_of_elephants_dream_3160kbps_2chn_48000Hz.mpg But it blocks before the pipeline gets into the state GST_STATE_PAUSED when replacing playbin with playbin2 The mpega and mpegv elements are custom made elements! When I attach a debuger I see 6 threads: - g_main_loop_run() waiting in poll - gst_multi_queue_loop() waiting in handle_pad_block() - gst_base_src_loop() driving the demuxer gst_mpeg_demux_send_subbuffer() waits in gst_data_queue_push() - gst_multi_queue_loop() doing gst_mpegvideoparse_chain() doing mpv_send_pending_segs() My mpegv decoder handles the NEWSEGMENT and then hangs in handle_pad_block() - gst_multi_queue_loop() doing a gst_mpegvideoparse_chain() My mpegv decoder is blocked in gst_pad_alloc_buffer_full() again because of handle_pad_block() - gst_multi_queue_loop() doing a gst_mp3parse_chain() My mpega decoder handles the NEWSEGMENT and then hangs in handle_pad_block() Is it normal to see 2 threads handling the video decoder related stuff? If not, what might be the reason? my gstreamer build is 0.10.25. PS I succeed rendering MPEGTS container with AAC and h264 with gst-launch using playbin2 I can also play MPEG 1 layer 1 audio with playbin2 ... I attach backtraces soon ...
Created attachment 145104 [details] These are the stack traces of all active threads
Just to reduce the number of possible causes... does it also hang if you do gst-launch-0.10 -v filesrc location=/path/to/file ! decodebin2 name=dbin dbin. ! ffmpegcolorspace ! autovideosink dbin. ! audioconvert ! autoaudiosink If it does, same threads, same places? Also note, that the two video pad blocks are for different pads. There seem to be two video streams here?
Also a debug log with GST_DEBUG=decodebin2:5 would be useful to have :)
OK, I figured out extra information. I feel I also need to give some background info. In the project I want to mainly parse MPEG TS. There are several plug-ins that seems to handle this that are selected by the playbin(2). Default libgstmpegdemux.so is used. My experience is that this one almost always fails working properly for a lot of MPEG TS streams. Therefore I made my own demuxer (fluendo's demuxer works the best however). I made a script that puts aside all unneeded plug-ins. Also mpegdemux was put aside due to poor performing on MPEG TS during my development of the mpega/mpegv elements. I used not MPEG TS container for testing but mpg ... That made that playbin selected some plug-in that can handle "making-of-el.-dream" mpg content but playbin2 does fail on this. After moving and compiling the latest gstreamer 0.10.25 modules, I found that suddenly I could play the content with playbin2. It turned out that the now visible mpegdemux was used as demuxer with playbin2. After moving aside, it stopped working again for playbin2, but works for playbin ...
Created attachment 145491 [details] Asked GST traces and other loggin when running the chain Here are the asked traces ... All are generated driving the pipeline with the playbin2. working means the mpegdemux element was available. Other log was made without the mpegdemux available. As explained before, in such case only playbin seems able to render. Playbin2 cannot handle the situation without the mpegdemux ...
Apart from that, I doubt the Fluendo's MPEG demuxer works better than mpegpsdemux (from gst-plugins-bad) or that Fluendo's MPEG TS demuxer works better than mpegtsdemux (also from gst-plugins-bad). They should only differ by the name ;) The MPEG demuxer from gst-plugins-ugly is not good though, that's known. But if you have the ones from gst-plugins-bad installed they will be used instead of the one from gst-plugins-ugly.
Could you also test the decodebin2 pipeline from above?
(In reply to comment #7) > Could you also test the decodebin2 pipeline from above? Sorry, I was adding a reply at the same moment as you :-) Here is the explanation: (In reply to comment #2) > Just to reduce the number of possible causes... does it also hang if you do > > gst-launch-0.10 -v filesrc location=/path/to/file ! decodebin2 name=dbin dbin. > ! ffmpegcolorspace ! autovideosink dbin. ! audioconvert ! autoaudiosink It works with mpegdemux element available. It fails without mpegdemux element When using "decodebin" It works with mpegdemux absent. It hangs with mpegdemux available ... This result is contrary to the findings of my own little program or using gst-launch: gst-launch-0.10 -v playbin uri=file:///home/francis/Desktop/making_of_elephants_dream_3160kbps_2chn_48000Hz.mpg works with or without mpegdemux available. > > If it does, same threads, same places? Also note, that the two video pad blocks > are for different pads. There seem to be two video streams here? I think so. While debugging my mpegv/mpega, originally I thought my coding of the mpegv element was causing the trouble. I saw indeed the mpegv _init() being invoked twice, from time to time (it might be that kdbg was playing tricks on me when most of the time my breakpoint was not reached the second time though ... on cet). Then I started using the gstmpeg2 (based on libmpeg2-0.5.1.tar.gz) and I saw the same behaviour.
(In reply to comment #6) > Apart from that, I doubt the Fluendo's MPEG demuxer works better than > mpegpsdemux (from gst-plugins-bad) or that Fluendo's MPEG TS demuxer works > better than mpegtsdemux (also from gst-plugins-bad). They should only differ by > the name ;) > The MPEG demuxer from gst-plugins-ugly is not good though, that's known. But if > you have the ones from gst-plugins-bad installed they will be used instead of > the one from gst-plugins-ugly. A, so there are demuxers in bad and ugly ... For fluendo I used "libtsmux-0.3.0.tar.bz2" and "gst-fluendo-mpegdemux-0.10.23.tar.bz2" Since i have my own one, it has been some time since I used fluendo's one... Thanks for pointing out! I investigate which one I'm actually using ...
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!