952102 - Fix VideoConduit unit tests

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, defect)

Comment 1

[Eric Rescorla (:ekr)]

Attachment: Fix VideoConduit unit tests

Comment 2

[Eric Rescorla (:ekr)]

The current VideoConduit test cases attempt to set up each conduit in
both sending and receiving mode, but they don't set "other" so that
the following check fails and the packets are dropped:

  if (mEngineReceiving)
  {
    if (mOtherDirection)
    {
      return mOtherDirection->SendPacket(channel, data, len);
    }
    CSFLogDebug(logTag,  "%s : Asked to send RTP without an RTP sender on channel %d",
                __FUNCTION__, channel);
    return -1;
  } else {


This change:
1. Adds actual checking that packets were received so that it detects this
failure.
2. Fixes the problem in the tests.

Arguably, there should be a check in VideoConduit that prohibits you from
doing this, at least an aseert or something.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 8350050 [details] [diff] [review]
Fix VideoConduit unit tests

Review of attachment 8350050 [details] [diff] [review]:
-----------------------------------------------------------------

r+, but this is a fraction of what should be done.  See a much more complete set of patches in bug 917916 (though designed to land on top of and old/outdated version of bug 864654, so they've bitrotted since the design for that bug changed).  That fixes this problem, makes the usage match our usage far better, and also adds checks for RTCP send and receive and bot unidirectional and bidirectional uses.

Comment 4

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/d95a2bcdf5cb

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/d95a2bcdf5cb