Bugzilla

`mozilla::AudioData::SetTrimWindow` is called with weird values. The printf I put in prints something like:

```
Data offset outside original buffer: 2354 > 2048 ([{1686645352037755,1000000}, {9223372036854775807,1000000}]({0,1000000}), [{16866453520132332,10000000}, {9223372036854775807,1000000}]({0,1000000}))
```
In this code we want to trim an audio buffer to start a bit later. But here we instruct it to start after its end.

The trim region is:

```
[{1686645352037755,1000000}, {9223372036854775807,1000000}]({0,1000000})
```

It's the seek target on the left bound, and the audio packet end on the right bound.

The audio packet is:

```
[{16866453520132332,10000000}, {9223372036854775807,1000000}]({0,1000000}))
```

I note that its base is in hundreds of nanoseconds, which are generally used on Windows, but never propagated down the code. It must be from an mp4 file that uses hns as a base, and then maybe there's an overflow somewhere.


The right bounds of the intervals are `+infinity`. The previous code would trim the entire buffer in this case and do nothing else: https://hg.mozilla.org/mozilla-central/rev/78068c6cc38f8ba0535d51af0f502078d7c0b02e#l1.20 (because infinity == infinity in this case), I'm going to restore this behaviour, but it's weird. I'll be adding some code in Nightly to catch those at the site of creation so we can get to the bottom of this.

`mozilla::AudioData::SetTrimWindow` is called with weird values. The printf I put in prints something like:

```
Data offset outside original buffer: 2354 > 2048 ([{1686645352037755,1000000}, {9223372036854775807,1000000}]({0,1000000}), [{16866453520132332,10000000}, {9223372036854775807,1000000}]({0,1000000}))
```
In this code we want to trim an audio buffer to start a bit later. But here we instruct it to start after its end.

The trim region is:

```
[{1686645352037755,1000000}, {9223372036854775807,1000000}]({0,1000000})
```

It's the seek target on the left bound, and the audio packet end on the right bound.

The audio packet is:

```
[{16866453520132332,10000000}, {9223372036854775807,1000000}]({0,1000000}))
```

I note that its base is in hundreds of nanoseconds, which are generally used on Windows, but never propagated down the code. It must be from an mp4 file that uses hns as a base, and then maybe there's an overflow somewhere. In any case, if we take typical packet sizes and typical sample rates, the seek target can lie in the correct packet, it's a bit more than 1024 frames later:

```
 > (1686645352037755/1000000. - 16866453520132332/10000000.) * 44100
1081.4126014709473
```

The right bounds of the intervals are `+infinity`. The previous code would trim the entire buffer in this case and do nothing else: https://hg.mozilla.org/mozilla-central/rev/78068c6cc38f8ba0535d51af0f502078d7c0b02e#l1.20 (because infinity == infinity in this case), I'm going to restore this behaviour, but it's weird. I'll be adding some code in Nightly to catch those at the site of creation so we can get to the bottom of this.

I'll get to the bottom of this in bug 1838275.

`mozilla::AudioData::SetTrimWindow` is called with weird values. The printf I put in prints something like:

```
Data offset outside original buffer: 2354 > 2048 ([{1686645352037755,1000000}, {9223372036854775807,1000000}]({0,1000000}), [{16866453520132332,10000000}, {9223372036854775807,1000000}]({0,1000000}))
```
In this code we want to trim an audio buffer to start a bit later. But here we instruct it to start after its end.

The trim region is:

```
[{1686645352037755,1000000}, {9223372036854775807,1000000}]({0,1000000})
```

It's the seek target on the left bound, and the audio packet end on the right bound.

The audio packet is:

```
[{16866453520132332,10000000}, {9223372036854775807,1000000}]({0,1000000}))
```

I note that its base is in hundreds of nanoseconds, which are generally used on Windows, but never propagated down the code. It must be from an mp4 file that uses hns as a base, and then maybe there's an overflow somewhere. In any case, if we take typical packet sizes and typical sample rates, the seek target can lie in the correct packet, it's a bit more than 1024 frames later, and the buffers are 2048 or 4096 frames according to the printf (example: https://crash-stats.mozilla.org/report/index/117ad0df-8f3d-4cad-9af6-5398e0230613):

```
 > (1686645352037755/1000000. - 16866453520132332/10000000.) * 44100
1081.4126014709473
```

The right bounds of the intervals are `+infinity`. The previous code would trim the entire buffer in this case and do nothing else: https://hg.mozilla.org/mozilla-central/rev/78068c6cc38f8ba0535d51af0f502078d7c0b02e#l1.20 (because infinity == infinity in this case), I'm going to restore this behaviour, but it's weird. I'll be adding some code in Nightly to catch those at the site of creation so we can get to the bottom of this.

I'll get to the bottom of this in bug 1838275.