[Bug 796361] Answer of RTSP server is (very) often not sent out

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=796361

--- Comment #8 from Marie Maurer <meinemailingliste2 at online.de> ---
The problem seems to be in gst_rtsp_media_prepare:

  fprintf(stderr, "MMMM I am in gst_rtsp_media_prepare Pos 10\n");

  /* now wait for all pads to be prerolled, FIXME, we should somehow be
   * able to do this async so that we don't block the server thread. */
  if (!wait_preroll (media))
  {
    fprintf(stderr, "MMMM I am in gst_rtsp_media_prepare Pos 11\n");
    goto preroll_failed;
  }

In the end we continue via preroll_failed.

static gboolean
wait_preroll (GstRTSPMedia * media)
{
  GstRTSPMediaStatus status;

  GST_DEBUG ("wait to preroll pipeline");

  /* wait until pipeline is prerolled */
  status = gst_rtsp_media_get_status (media);
  if (status == GST_RTSP_MEDIA_STATUS_ERROR)
    goto preroll_failed;

  return TRUE;

preroll_failed:
  {
    GST_WARNING ("failed to preroll pipeline");
    return FALSE;
  }
}

I see 
wait_preroll: wait to preroll pipeline
wait_preroll: failed to preroll pipeline
gst_rtsp_media_prepare: failed to preroll pipeline

The wait_preroll seems to block exactly (!) for 20 seconds.
(time between "wait to preroll pipeline" and "failed to preroll pipeline"
and debug output "Pos 10" and "Pos 11").
Is "20 seconds" something which triggers an idea?

My current assumption: 
I assume my pipeline has some problems to get prerolled.
Perhaps some side effects with our HW encoder (on i.MX6) using DMA buffers.
I try to compile and test some RTSP test application, 
so it is hopefully easier to find out the root cause of the problem.

@Tim
echo 1 > /proc/sys/net/ipv4/tcp_low_latency
seems to make no difference in the behaviour.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.