GNOME Bugzilla – Bug 727821
souphttpsrc: Regression in push mode
Last modified: 2014-04-09 08:57:35 UTC
oggdemux doesn't work in push mode anymore because it's forwarding the EOS from souphttpsrc seeking to the end of the file to determine the duration. The regressions seems to have been introduced in: commit 0173afa38cc6f8a2cb810f99a24ddb1d5d5f4868 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Sat Aug 13 14:18:56 2011 +0100 oggdemux: implement push mode seeking +#if 0 + /* This would be what is needed (recover from EOS by going on to + the next step (issue the delayed seek)), but it does not work + if there is a queue2 upstream - see more details comment in + gst_ogg_pad_submit_page. + If I could find a way to bypass queue2 behavior, this should + be enabled. */ + GST_PUSH_LOCK (ogg); + if (ogg->push_state == PUSH_DURATION) { + GST_DEBUG_OBJECT (ogg, "Got EOS while determining length"); + res = gst_ogg_demux_seek_back_after_push_duration_check_unlock (ogg); + if (res != GST_FLOW_OK) { + GST_DEBUG_OBJECT (ogg, "Error seeking back after duration check: %d", + res); + } + break; + } + GST_PUSH_UNLOCK (ogg); +#endif It can be easilly reproduced with: gst-launch-1.0 playbin uri=http://docs.gstreamer.com/media/sintel_trailer-368p.ogv
Works for me with latest git (core, -base, -good). This hunk adds defined out code, does not change behavior. The duration check seeks near the end, but not right to the end, in order to avoid the EOS, which can shut down upstream tasks. I guess something upstream overreads anyway. If that's the case, increasing EOS_AVOIDANCE_THRESHOLD might fix it, though probably not very well. Enabling the code you quoted might too, but it will not cause any upstream task to restart if they stopped from the EOS.
It looks more like souphttsrc's fault. Reverting this commit make it work again: commit ac839610334a1ad34177f419bd22a2481e9b5d89 Author: Sebastian Dröge <sebastian@centricular.com> Date: Fri Mar 7 16:17:29 2014 +0100 souphttpsrc: Make sure to not return EOS immediately if we finished a range request Only return EOS the next time create() is called, if at all. basesrc should already take care of not calling it again. Also always return immediately if the previous flow return was not OK. This indicates an error somewhere.
Also happens with mp4 files: http://media.w3.org/2010/05/sintel/trailer.mp4
Most simple testcase: > gst-launch-1.0 souphttpsrc location=http://media.w3.org/2010/05/sintel/trailer.mp4 ! queue2 use-buffering=true ! qtdemux ! fakesink sync=true
commit d918212e127a1cfe9b19ecc514f4835c5ee00ea9 Author: Sebastian Dröge <sebastian@centricular.com> Date: Wed Apr 9 10:56:29 2014 +0200 souphttpsrc: Use GST_FLOW_FLUSHING when flushing, not GST_FLOW_EOS ... and reset it properly after flushing is done. Fixes playback in many cases when buffering is used. https://bugzilla.gnome.org/show_bug.cgi?id=727821