GNOME Bugzilla – Bug 728017
[regression]eos event could not be send out from gstrtpjitterbuffer.
Last modified: 2014-04-18 14:10:54 UTC
Created attachment 274063 [details] log file for gstrtpjitterbuffer. i tried to play rtsp streaming and the playback could not stop when played to end of stream. I traced the event and find out gstrtpjitterbuffer received the eos event but did not send it out. it will wait in function gst_rtp_jitter_buffer_loop(). my pipeline is: gst-launch-1.0 playbin uri=rtsp://10.192.225.226/rtsp/sample_h264_1mbit.mp4
commit 42cfedde7fab7763ef67da7081d34467acd1083d Author: Wim Taymans <wtaymans@redhat.com> Date: Fri Apr 18 04:23:26 2014 +0200 jitterbuffer: assume a full buffer when eos Rework the logic to make buffering messages a little, make sure we don't make the same message multiple times. Consider the buffer full when EOS was received. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=728017
Hi: I merged the commit to 1.2.3 branch but it does not resolved the issue. Eos event was found about 5*5 seconds behind the last buffer. However, rtp_jitter_buffer_is_buffering always returns TRUE and it will keeps waiting the event. Here is my solution: static GstFlowReturn handle_next_buffer (GstRtpJitterBuffer * jitterbuffer) { GstRtpJitterBufferPrivate *priv = jitterbuffer->priv; GstFlowReturn result = GST_FLOW_OK; RTPJitterBufferItem *item; guint16 seqnum; guint32 next_seqnum; gint gap; + if(priv->eos) + return GST_FLOW_EOS; /* only push buffers when PLAYING and active and not buffering */ if (priv->blocked || !priv->active || rtp_jitter_buffer_is_buffering (priv->jbuf)) return GST_FLOW_WAIT;
(In reply to comment #2) > Hi: > I merged the commit to 1.2.3 branch but it does not resolved the issue. Be careful with porting to 1.2, it causes conflicts. The 1.2 merged patch is here: http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?h=1.2&id=498e2e082261d16f285fd8c34852fe862b33fdd3 I tested with rtsp-server streaming sample_h264_1mbit.mp4 and it worked correctly for me. > Eos event was found about 5*5 seconds behind the last buffer. > However, rtp_jitter_buffer_is_buffering always returns TRUE and it will keeps > waiting the event. It sounds like you are not testing the right patch. With the patch, In the EOS case, check_buffering_percent() will set buffering to FALSE. > > Here is my solution: The problem with your solution is that EOS is sent too soon, you first need to push out all the buffers from the jitterbuffer and then check EOS. If you believe you tried the right patch, can you make a new debug log and reopen this bug?
Created attachment 274648 [details] log with new patch Eos event was received at 0:01:37 I stop the pipeline by manual at 0:03:10.
Ok, I see now. The server does not send a BYE packet and thus the EOS is generated because of the session timeout.
This should fix it completely, will push backport to 1.2 soon commit 3e11ce43b9e83aff5d92e6209e38d268d564edcf Author: Wim Taymans <wtaymans@redhat.com> Date: Fri Apr 18 11:11:14 2014 +0200 jitterbuffer: improve EOS handling Make a new method to disable the jitterbuffer buffering. Rework the update_estimated_eos() method. Calculate how much time there is left to play. If we have less than the delay of the jitterbuffer, we disabled buffering because we might never be able to fill the complete jitterbuffer again. If we receive an EOS event, disable buffering. We will drain the buffer and eventually push the EOS event out. When we reach the estimated NPT timeout and we didn't receive an EOS event, make one and queue it so that it can be pushed. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=728017
Thanks. I will try it on Monday.