[Bug 772646] rtpjitterbuffer: fix lost-event using dts instead of pts

[GStreamer (GNOME Bugzilla)]

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

--- Comment #9 from Håvard Graff (hgr) <havard.graff at gmail.com> ---
So I have experimented a bit over the last few days, and I can't make it
fail...

Here is the test I ended up writing:

GST_START_TEST (test_single_bad_packet_in_stream)
{
  GstHarness *h = gst_harness_new ("rtpjitterbuffer");
  GstClockTime now = 0;
  const gint num_consecutive = 5;
  gint i;

  g_object_set (h->element, "latency", 80, NULL);

  gst_harness_set_src_caps (h, generate_caps ());

  for (i = 0; i < num_consecutive; i++) {
    gst_harness_set_time (h, now);
    fail_unless_equals_int (GST_FLOW_OK, gst_harness_push (h,
        generate_test_buffer_full (now, TRUE, i, i * PCMU_RTP_TS_DURATION)));
    now += PCMU_BUF_DURATION;
  }

  fail_unless (gst_harness_crank_single_clock_wait (h));

  for (i = 0; i < num_consecutive; i++) {
    GstBuffer *buf = gst_harness_pull (h);
    fail_unless_equals_int (i, get_rtp_seq_num (buf));
    fail_unless_equals_uint64 (i * PCMU_BUF_DURATION, GST_BUFFER_PTS (buf));
    gst_buffer_unref (buf);
  }

  /* push one packet with a completely wrong sequence number and rtp-timestamp
*/
  fail_unless_equals_int (GST_FLOW_OK, gst_harness_push (h,
      generate_test_buffer_full (now, TRUE, 1000, 22222 *
PCMU_RTP_TS_DURATION)));


  /* and then continue the same flow of buffers */
  for (i = num_consecutive; i < num_consecutive * 2; i++) {
    gst_harness_set_time (h, now);
    fail_unless_equals_int (GST_FLOW_OK, gst_harness_push (h,
        generate_test_buffer_full (now, TRUE, i, i * PCMU_RTP_TS_DURATION)));
    now += PCMU_BUF_DURATION;
  }

  for (i = num_consecutive; i < num_consecutive * 2; i++) {
    GstBuffer *buf = gst_harness_pull (h);
    fail_unless_equals_int (i, get_rtp_seq_num (buf));
    fail_unless_equals_uint64 (i * PCMU_BUF_DURATION, GST_BUFFER_PTS (buf));
    gst_buffer_unref (buf);
  }

  gst_harness_teardown (h);
}

GST_END_TEST;


As you can see, I verify that pts is correct on all outgoing buffers, and for
the one "bad" packet in the middle there, I am able to trigger a few different
code-paths (some of which looks like bugs) by changing the seqnum and
rtp-timestamp to various things, but I am unable to make the stream fail. Maybe
you could try and experiment a bit with that test to see if you can get a
failing scenario I could work with?

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