GNOME Bugzilla – Bug 395476
gst_element_get_state hangs when reading an ogm file
Last modified: 2007-01-11 18:05:55 UTC
I've built a pipeline (filesrc, oggdemux, ffdec_mpeg4, and a specific sink) to read an ogm video file (with xvid + vorbis streams). When I set the pipeline to PAUSED, it hangs when I call gst_element_get_state. Here is the backtrace:
+ Trace 101315
you can download the program I use there: http://www.maths.univ-evry.fr/pages_perso/vtorri/files/gstreamer_test_seek/gst_seek.tar.bz2 just untar the archive, go into gst_seek and run make. It install the sink in ~/.gstreamer-0.10/plugins and create the test program seek_ogm. Pass the ogm file as an argument to that prog. The file I use : http://www.maths.univ-evry.fr/pages_perso/vtorri/files/gstreamer_test_seek/blood.ogm
for ogm, the demuxer will create a application/x-ogm-video pad that you should connect to ogmvideoparse and then to the video decoder. The reason this pipeline blocks waiting for preroll is because the sink is never connected and thus doesn't preroll. You get an error, though (all pads unlinked), which you would have catched on the bus.
(Bah, Wim was faster than me, but since I typed all this I might just as well post ;-)) This is a bug in your application. For one, you must at least watch for ERROR messages on the bus (so you can shut down your pipeline and _get_state() will return in case of an ERROR). $ GST_DEBUG=*:2 ./seek_ogm ~/samples/video/ogm/351790.ogm WARN gstoggdemux.c:2291:gst_ogg_demux_read_chain:<demuxer> failed to read chain new pad (str='application/x-ogm-video') new pad (str='audio/x-vorbis') new pad (str='audio/x-vorbis') new pad (str='application/x-ogm-text') WARN gstoggdemux.c:3000:gst_ogg_demux_loop:<demuxer> error: Internal data stream error. WARN gstoggdemux.c:3000:gst_ogg_demux_loop:<demuxer> error: stream stopped, reason not-linked The first warning is harmless, the second not so much. It describes the error message that has been posted on the bus. The bug in your application is that you are assuming that oggdemux creates pad of video/* type, which is not the case. You need to plug a ogmvideoparse after oggdemux in this case. You might also want to connect to the 'no-more-pads' signal and shut down the pipeline if you get it but haven't connected a video pad yet.