iSAC: Pad with zeros instead of random data, to make testing easier

iSAC: Pad with zeros instead of random data, to make testing easier

Using random "garbage" bytes makes testing harder for no good reason.
Any deterministic sequence would do, but we choose all zeros because
it's simple.

Committed: https://crrev.com/f4eca64596f8d29eeaedd9365177d8004a0cac4a
Cr-Commit-Position: refs/heads/master@{#9532}

[kwiberg-webrtc, 2015-07-01 13:46:43]

Patchset #1 (id:1) has been deleted

[kwiberg-webrtc, 2015-07-01 13:51:49]

kwiberg@webrtc.org changed reviewers:
+ henrik.lundin@webrtc.org, tina.legrand@webrtc.org, turaj@webrtc.org

[kwiberg-webrtc, 2015-07-01 13:51:49]

kwiberg@webrtc.org changed required reviewers:
+ tina.legrand@webrtc.org, turaj@webrtc.org

[kwiberg-webrtc, 2015-07-01 13:56:55]

I need the determinism part of this for another CL. iSACfix is already
deterministic, since it uses a deterministic pseudorandom number generator, but
I don't see a reason why we can't just pad with zeros instead, so that's what I
did.

[turaj, 2015-07-01 14:15:19]

On 2015/07/01 13:56:55, kwiberg1 wrote:
> I need the determinism part of this for another CL. iSACfix is already
> deterministic, since it uses a deterministic pseudorandom number generator,
but
> I don't see a reason why we can't just pad with zeros instead, so that's what
I
> did.

You know that the reason to add garbage to payload is that iSAC can measure if
available bandwidth has been increased. The historic reason for adding random
sequence rather than a fixed value has been--as far as I asked and got the
answer--that some modem would compress payloads if they can, and many fixed
values are easy to compress, which defeats the purpose. How much this argument
is valid, I have to idea. If we are sure nothing like that would happen then we
can make this change. 

Are you writing bit-exact test that random sequence makes it difficult, just
curious?

[kwiberg-webrtc, 2015-07-01 14:51:51]

On 2015/07/01 14:15:19, turaj wrote:
> On 2015/07/01 13:56:55, kwiberg1 wrote:
> > I need the determinism part of this for another CL. iSACfix is already
> > deterministic, since it uses a deterministic pseudorandom number generator,
> but
> > I don't see a reason why we can't just pad with zeros instead, so that's
what
> I
> > did.
> 
> You know that the reason to add garbage to payload is that iSAC can measure if
> available bandwidth has been increased.

Yes.

> The historic reason for adding random
> sequence rather than a fixed value has been--as far as I asked and got the
> answer--that some modem would compress payloads if they can, and many fixed
> values are easy to compress, which defeats the purpose. How much this argument
> is valid, I have to idea. If we are sure nothing like that would happen then
we
> can make this change.

I'm not sure that compression isn't still going on in e.g. some low-speed mobile
networks. But compression in the channel can only make our packets smaller if
we're not encrypting, and I seriously hope that's never the case.

> Are you writing bit-exact test that random sequence makes it difficult, just
> curious?

In https://codereview.webrtc.org/1208923002/, I want to test that separating the
encoder from the decoder gives identical packets.

[turaj, 2015-07-01 17:54:38]

lgtm

[tlegrand-webrtc, 2015-07-02 08:16:33]

On 2015/07/01 at 14:15:19, turaj wrote:
> On 2015/07/01 13:56:55, kwiberg1 wrote:
> > I need the determinism part of this for another CL. iSACfix is already
> > deterministic, since it uses a deterministic pseudorandom number generator,
but
> > I don't see a reason why we can't just pad with zeros instead, so that's
what I
> > did.
> 
> You know that the reason to add garbage to payload is that iSAC can measure if
available bandwidth has been increased. The historic reason for adding random
sequence rather than a fixed value has been--as far as I asked and got the
answer--that some modem would compress payloads if they can, and many fixed
values are easy to compress, which defeats the purpose. How much this argument
is valid, I have to idea. If we are sure nothing like that would happen then we
can make this change. 

We can probably disregard that risk.

> 
> Are you writing bit-exact test that random sequence makes it difficult, just
curious?

[tlegrand-webrtc, 2015-07-02 08:16:38]

lgtm

[kwiberg-webrtc, 2015-07-02 08:28:00]

The CQ bit was checked by kwiberg@webrtc.org

[commit-bot: I haz the power, 2015-07-02 08:28:11]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1211243014/20001

[commit-bot: I haz the power, 2015-07-02 09:10:13]

Committed patchset #1 (id:20001)

[commit-bot: I haz the power, 2015-07-02 09:10:19]

Patchset 1 (id:??) landed as
https://crrev.com/f4eca64596f8d29eeaedd9365177d8004a0cac4a
Cr-Commit-Position: refs/heads/master@{#9532}