GNOME Bugzilla – Bug 602885
shout2send plugin ignores seek events.
Last modified: 2009-12-01 21:24:08 UTC
Created attachment 148425 [details] Test case demonstrating bug. Attached is a simple test case. When a pipeline containing a shout2send element receives a seek event, the result is to pause and then immediately resume playback but not to adjust the position. Running the attached test case with --gst-debug=3 yields the following output: 0:00:15.148535613 28033 0x8196008 INFO GST_EVENT gstevent.c:974:gst_event_new_seek: creating seek rate 1.000000, format TIME, flags 1, start_type 2, start 0:00:00.000000000, stop_type 3, stop 0:00:00.000000000 0:00:15.484565817 28033 0x82a9d18 INFO basesrc gstbasesrc.c:2278:gst_base_src_loop:<filesrc0> pausing after gst_pad_push() = wrong-state Seeked backwards. 0:00:15.485438260 28033 0x82a9d18 WARN basesink gstbasesink.c:2884:gst_base_sink_chain_unlocked:<shout2send0> warning: Internal data flow problem. 0:00:15.485481561 28033 0x82a9d18 WARN basesink gstbasesink.c:2884:gst_base_sink_chain_unlocked:<shout2send0> warning: Received buffer without a new-segment. Assuming timestamps start from 0. 0:00:15.485552868 28033 0x82a9d18 INFO GST_ERROR_SYSTEM gstelement.c:1675:gst_element_message_full:<shout2send0> posting message: Internal data flow problem. 0:00:15.485616213 28033 0x82a9d18 INFO GST_ERROR_SYSTEM gstelement.c:1698:gst_element_message_full:<shout2send0> posted warning message: Internal data flow problem.
A filesrc only knows about bytes, you can't seek in time. An ogg parser element could be wrriten that could perform the conversion from time to bytes. Please reopen and rename this bug if that is what you want.
I actually see the same behavior if the stream is decoded and reencoded; is that expected? For example, consider the following pipeline: filesrc ! oggdemux ! vorbisdec ! vorbisenc ! oggmux ! shout2send This stream likewise fails to seek. However, if the output goes to a local audio device, then seeking works fine: filesrc ! oggdemux ! vorbisdec ! audioconvert ! audioresample ! alsasink Is the issue with the first pipeline above that the stream passed between oggmux and shout2send is not time based and therefore unseekable? If so, is there any workaround to seek the input to a shout2send element, given that its input will always be audio/mpeg or audio/ogg? Thanks for your thoughts. --Ian
I don't think oggmux supports seeking yet. If you want time based seeking you either need to have some element that looks at the timestamps in the file (like a parser) or perform the seek in bytes, based on the (average) bitrate. If you know the length in time of the file and assume a constant bitrate, then you can estimate the time position in bytes and perform a seek in bytes (which should work fine).
Wim, The first pipeline of comment 2 contains a parser element but still won't seek; are you suggesting that if the seek event were directed to a particular element (such as vorbisdec) then it would work correctly? Or are you saying that it would, except that oggmux doesn't support seeking?