[gstreamer-bugs] [Bug 395476] gst_element_get_state hangs when reading an ogm file

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=395476

  GStreamer | gst-plugins-base | Ver: HEAD CVS


Tim-Philipp Müller changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|NOTABUG                     |INVALID
   Target Milestone|HEAD                        |NONE




------- Comment #2 from Tim-Philipp Müller  2007-01-11 18:05 UTC -------
(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.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email