GNOME Bugzilla – Bug 559547
Seek bugs when playing rtsp video in m.youtube.com
Last modified: 2009-01-23 08:42:38 UTC
Please describe the problem: 1. Seek fails when playing rtsp video in m.youtube.com. Rtspsrc sends a `PLAY' method which includes a `Range' header to implement seeking but youtube requires `PAUSE' first. In short words, we should send `PAUSE', then `PLAY' to make seek works. Send `PLAY' directly will make youtube server responses a bad request. 2. I use `gst_element_seek(pipeline, 1.0, GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH, GST_SEEK_TYPE_SET, seek_position, GST_SEEK_TYPE_NONE, GST_CLOCK_TIME_NONE)' to perform the seek. Seek works but the return value of this call is FALSE. Steps to reproduce: 1. Use rtspsrc to play the movie in m.youtube.com then seek. Actual results: Seek fails and gst_element_seek returns FALSE Expected results: gst_element_seek returns TRUE and the seeking is correct Does this happen every time? Yes Other information:
Created attachment 122073 [details] [review] patch of gstrtspsrc.c for the seek issues
Comment on attachment 122073 [details] [review] patch of gstrtspsrc.c for the seek issues 1. I call the `gst_rtspsrc_pause' in seek function to make sure the `PAUSE' method will be sent before we send the `PLAY' method again. 2. The reason for the `gst_element_seek' returns FALSE is pipeline will not only send seek event to audio/video sinks but also to rtspsrc . This is because rtspsrc is a sink element as well. So I overrides the send event function pointer to make sure the seek event will not be sent down to the elements which resides in rtspsrc. In this way, gst_element_seek returns TRUE.
I simply removed the IS_SINK flags from the udpsinks so that rtspsrc is never considered a sink. Based on patch by: Eric Zhang <chao.zhang at access-company dot com> * gst/rtsp/gstrtspsrc.c: (gst_rtspsrc_perform_seek), (gst_rtspsrc_stream_configure_udp_sink): Pause the RTSP stream before doing a new play request. Make sure that adding the udpsinks does not cause the rtspsrc to become a sink. Fixes #559547.