Opus issueshttps://gitlab.xiph.org/xiph/opus/-/issues2020-04-22T04:19:26Zhttps://gitlab.xiph.org/xiph/opus/-/issues/2315Minor Issue on libopus 1.3-rc default framesize adjustment2020-04-22T04:19:26ZHeman BusschotsMinor Issue on libopus 1.3-rc default framesize adjustmentHi,
I couldn't post on the IRC for some reason, that's why I want to post it here.
On the libopus 1.3-rc (release candidate), I found it best to change the Framesize setting to 40.
In my case I could increase bitrate from 48kbps to 51kbp...Hi,
I couldn't post on the IRC for some reason, that's why I want to post it here.
On the libopus 1.3-rc (release candidate), I found it best to change the Framesize setting to 40.
In my case I could increase bitrate from 48kbps to 51kbps, where artifacts are hardly heard, while keeping the same file size.
These 3 extra bits, may seem little, but they're the difference between noticeable artifacts at 48kbps (in the stereo spectrum) to nearly fully transparent at 51kbps; all the while keeping the same file size.
Audio quality overall improved slightly thanks to this setting.
Setting it larger or smaller, did not increase quality or decrease filesize.
With that I just want to say that in my opinion, the newer release candidate, runs better with Framesize 40.
It would be nice to further be able to finetune this (between the ranges of 20-60) to see where the exact best setting is located.
The best framesize setting, could be 30, or it could be 45, without the ability to tune it any other than 20, 40, or 60, I wouldn't know...
Not sure if Opus can support such a feature?
Just like CPU complexity is by default set to 10, I think framesize should be set to 40 by default, on the RC candidate (1.3).
Aside from allowing a 6% higher bitrate, while keeping the same file size, it also allows for going much lower in bitrate before capping off the high frequencies.
For instance, For stereo music, I can go as low as 24kbps at almost 48kHz (I think it's capped to 32, but it's mostly inaudible); and for mono I can go as low as 12kbps, before the high frequencies are cut.
Using Framebuffer 20 or 60, has higher tresholds.https://gitlab.xiph.org/xiph/opus/-/issues/1997Opus trunk/1.1 fails to build - 'export' is a GNU make-ism2020-04-22T04:16:23ZBrad SmithOpus trunk/1.1 fails to build - 'export' is a GNU make-ismOpus trunk/1.1 has had someregressions over 1.0.x and fails to build..
checking for C99 variable-size arrays... yes
checking for cos in -lm... (cached) yes
/home/ports/pobj/opus-1.1/opus-1.1/configure[12816]:
${inline_optimization:0:3}...Opus trunk/1.1 has had someregressions over 1.0.x and fails to build..
checking for C99 variable-size arrays... yes
checking for cos in -lm... (cached) yes
/home/ports/pobj/opus-1.1/opus-1.1/configure[12816]:
${inline_optimization:0:3}": bad substitution
AM_CONDITIONAL([OPUS_ARM_INLINE_ASM],
[test x"${inline_optimization:0:3}" = x"ARM"])
AM_CONDITIONAL([OPUS_ARM_EXTERNAL_ASM],
[test x"${asm_optimization:0:3}" = x"ARM"])
*** Parse error in /home/ports/pobj/opus-1.1/build-amd64: Need an
operator in 'yes' (Makefile:2756)
# Provide the full test output for failed tests when using the parallel
# test suite (which is enabled by default with automake 1.13+).
export VERBOSE = yes
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1937opusenc : problem sample causes clipping2019-09-13T15:02:02ZJulian Hughesopusenc : problem sample causes clippingEncoding this 10 second pcm wav sample with opusenc 0.1.6 causes obvious clipping (repeated clicks in right channel) from about 7 seconds.
I tried default:
opusenc sample.wav sample.opus
That produced a file opusinfo shows as:
Average ...Encoding this 10 second pcm wav sample with opusenc 0.1.6 causes obvious clipping (repeated clicks in right channel) from about 7 seconds.
I tried default:
opusenc sample.wav sample.opus
That produced a file opusinfo shows as:
Average bitrate: 124.4 kb/s, w/o overhead: 123.3 kb/s
then I tried:
opusenc --bitrate 160 sample.wav sample_160.opus
That produced a file opusinfo shows as:
Average bitrate: 198 kb/s, w/o overhead: 196.8 kb/s
The 160 target file also clips.
Then I tried:
opusenc --bitrate 192 sample.wav sample_192.opus
That produced a file opusinfo shows as:
Average bitrate: 229.2 kb/s, w/o overhead: 227.7 kb/s
That plays without clipping. This is quite similar to Ogg Vorbis which on the same sample clips at -q 6 but is OK at -q 7. The sample is pcm from my retail CD and hasn't been touched by a lossy encoder. I've compressed it to flac for attachment.
Here are examples of what I did so you can see the version I'm using:
$ opusenc sample.wav sample.opus
Skipping chunk of type "LIST", length 26
Encoding using libopus 1.1-alpha (audio)
-----------------------------------------------------
Input: 44.1kHz 2 channels
Output: 2 channels (2 coupled)
20ms packets, 96kbit/sec VBR
Preskip: 356
Encoding complete
-----------------------------------------------------
Encoded: 10.02 seconds
Runtime: 1 seconds
(10.02x realtime)
Wrote: 155636 bytes, 501 packets, 13 pages
Bitrate: 123.112kbit/s (without overhead)
Rate range: 92.8kbit/s to 193.6kbit/s
(232 to 484 bytes per packet)
Overhead: 0.924% (container+metadata)
$ opusinfo sample.opus
Processing file "sample.opus"...
New logical stream (#1, serial: 1ce42e69): type opus
Encoded with libopus 1.1-alpha
User comments section follows...
ENCODER=opusenc from opus-tools 0.1.6
Opus stream 1:
Pre-skip: 356
Playback gain: 0 dB
Channels: 2
Original sample rate: 44100Hz
Packet duration: 20.0ms (max), 20.0ms (avg), 20.0ms (min)
Page duration: 1000.0ms (max), 910.9ms (avg), 20.0ms (min)
Total data length: 155636 bytes (overhead: 0.924%)
Playback length: 0m:10.007s
Average bitrate: 124.4 kb/s, w/o overhead: 123.3 kb/s
Logical stream 1 ended
This is on i386 Debian Wheezy/Testing on AMD Athlon64 CPU. I built opus-tools from the tarball supplied at http://www.opus-codec.org/downloads.
I also built ffmpeg and opus from current git (yesterday) and get identical results when using ffmpeg -c:a libopus.
I tried playback/decoding with and without software sample rate conversion and ruled out any possibility of sample rate conversion artefacts. I got the same clipping whether running opusdec alone or doing 'opusdec sample.opus --force-wav - |mplayer -'Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1894exp_analysis doesn't work in fixed-point2018-11-26T18:44:40ZJean-Marc Valinexp_analysis doesn't work in fixed-pointThe exp_analysis branch added some float operations that need to be converted to fixed-point or #ifdef'ed out.The exp_analysis branch added some float operations that need to be converted to fixed-point or #ifdef'ed out.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1918OggIndex needs opus support2018-11-26T18:44:40ZGitlab BotOggIndex needs opus supportRight now one can not use Ogg with Theora and Opus with an index.
As a first step OggIndex needs support for Opus.
http://git.xiph.org/?p=OggIndex.git;a=tree
Right now one can not use Ogg with Theora and Opus with an index.
As a first step OggIndex needs support for Opus.
http://git.xiph.org/?p=OggIndex.git;a=tree
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1926Enhanced spatialization can lead to high-frequency swishiness after mixing do...2018-11-26T18:44:40ZkarlnordstromEnhanced spatialization can lead to high-frequency swishiness after mixing down to monoEnhanced spatialization during encoding can result in high-frequency swishiness after mixdown to mono. The problem becomes evident when the following conditions are true:
1. The encoder captures far-field (across-the room) audio in ster...Enhanced spatialization during encoding can result in high-frequency swishiness after mixdown to mono. The problem becomes evident when the following conditions are true:
1. The encoder captures far-field (across-the room) audio in stereo, and
2. the decoder side mixes the audio down to mono.
This can occur when the receiving side has a mono speaker. This is likely to occur in multi-chat with a mix of devices doing hands-free communication.
Reproducing the problem:
1. Capture far-field (across the room) speech with stereo mics.
2. Encode and decode with Opus.
3. Mix down to mono.
4. Listen.
Expected result:
Mono audio without audio artifacts.
Observed result:
High frequency "swishiness" due to high-frequency phase issues.
One (sub-optimal) solution is to just use the right or left channel for the mono signal instead of mixing the audio down to mono. However, this means that the mono signal will lose key information from the other channel.
The following patch eliminates the above-mentioned artifacts by not doing additional spatialization:
```
$ git diff
diff --git a/celt/bands.c b/celt/bands.c
index 62f0ee7..f493a81 100644
--- a/celt/bands.c
+++ b/celt/bands.c
@@ -794,7 +794,7 @@ static void compute_theta(struct band_ctx *ctx, struct split_ctx *sctx,
} else if (stereo) {
if (encode)
{
- inv = itheta > 8192;
+ inv = 0; // Don't reverse phase. leads to high-freq "swishiness" on mixdown to mono.
if (inv)
{
int j;
```
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1949genversion.bat doesn't work if path contains a space2018-11-26T18:44:40ZDietrich Eppgenversion.bat doesn't work if path contains a spaceOn Windows, the `genversion.bat` script doesn't seem to work if the path contains a space, e.g., `C:\Users\John Doe\...`. It works fine if I move the project to a path containing no spaces. Maybe the script could start with `cd` and th...On Windows, the `genversion.bat` script doesn't seem to work if the path contains a space, e.g., `C:\Users\John Doe\...`. It works fine if I move the project to a path containing no spaces. Maybe the script could start with `cd` and then work with relative paths?Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1952opus 1.0.2 not working fine in windows (xp/7)2018-11-26T18:44:40Zsasugumaropus 1.0.2 not working fine in windows (xp/7)i unzipped the opus 1.0.2 and build in windows xp. i tried to decode "testvector01.bit" which i hav downloaded from www.opus_codec.org.
with command arguments "-d 48000 2 testvector01.bit testvector01.pcm".
"testvector01.pcm" not matc...i unzipped the opus 1.0.2 and build in windows xp. i tried to decode "testvector01.bit" which i hav downloaded from www.opus_codec.org.
with command arguments "-d 48000 2 testvector01.bit testvector01.pcm".
"testvector01.pcm" not matching with "testvector01.dec" ref testvector.
but it is matching if it decoded in linux ubuntu. it is working fine with same arguments.
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1954celt_decode_lost() - very poor precision/wrong result in application of frac_...2018-11-26T18:44:40ZJ.Dodscelt_decode_lost() - very poor precision/wrong result in application of frac_div32( arg1, arg2 )
## Looking in celt_decode_lost() under the comment:
```
/* Check if the waveform is decaying (and if so how fast)
We do this to avoid adding energy when concealing in a segment
with decaying energy */
decay = celt_sqrt(...
## Looking in celt_decode_lost() under the comment:
```
/* Check if the waveform is decaying (and if so how fast)
We do this to avoid adding energy when concealing in a segment
with decaying energy */
decay = celt_sqrt( frac_div32(SHR32(E1,1),E2) );
```
We see that if E1=1 then the 1-bit right shift of E1 makes E1=0. Therefore ANY E1, E2 combinations like 1/2, 1/3, ... 1/n will evaluate to zero.
Similarly, for small values of E1 the precision of the result is needlessly poor (see table below).
Suggested fix: If the intent of shifting was done to bound the output of frac_div32 to (0.5,0] then an alternate solution which avoids the E1=1 pitfall (and poor precision on small values of E1) is to shift the _result_ of frac_div32(), instead.
```
decay = celt_sqrt( frac_div32(E1,E2)>>1 );
```
Here is a small table of test values to illustrate:
decay = celt_sqrt ( frac_div32(SHR32(E1,1),E2) );
====================================================
7FEB = celt_sqrt( 3FF36D10 = frac_div32(1303/1303)) <-- so-so
687C = celt_sqrt( 2AAAAAA0 = frac_div32( 11/ 15)) <-- not great
5A86 = celt_sqrt( 1FFFFFF0 = frac_div32( 3/ 4)) <-- very bad
0000 = celt_sqrt( 00000000 = frac_div32( 1/ 1)) <-- wrong
With suggested code fix:
decay = celt_sqrt( frac_div32(E1,E2)>>1 );
====================================================
7FF6 = celt_sqrt( 3FFFFFF8 = frac_div32(1303/1303))
6D97 = celt_sqrt( 2EEEEEE8 = frac_div32( 11/ 15))
6ED5 = celt_sqrt( 2FFFFFF8 = frac_div32( 3/ 4))
7FF6 = celt_sqrt( 3FFFFFF8 = frac_div32( 1/ 1))
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1955what is the encoding parameters usef for opus testvectorx.bit2018-11-26T18:44:40Zsasugumarwhat is the encoding parameters usef for opus testvectorx.bithi! thanks for last reply. i am getting hard to find, what is the encoding parameters that is used for coding in the Bitconformance testvectorx.bit. pls send or ref some link regarding this.
i found decoding parameters
-d 48000 2 testv...hi! thanks for last reply. i am getting hard to find, what is the encoding parameters that is used for coding in the Bitconformance testvectorx.bit. pls send or ref some link regarding this.
i found decoding parameters
-d 48000 2 testvectorx.bit testx.out
any help greatly appreciated.
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1961libopus and libspeex can not be statically linked in same application2018-11-26T18:44:40ZGitlab Botlibopus and libspeex can not be statically linked in same applicationtrying to link libopus and libspeex in a static application on OS X (i.e. ffmpeg) fails due to duplicate symbols:
```
ld: duplicate symbol _pitch_xcorr in lib/libopus.a(pitch.o) and lib/libspeex.a(ltp.o)
```
to work around this, pitch_...trying to link libopus and libspeex in a static application on OS X (i.e. ffmpeg) fails due to duplicate symbols:
```
ld: duplicate symbol _pitch_xcorr in lib/libopus.a(pitch.o) and lib/libspeex.a(ltp.o)
```
to work around this, pitch_xcorr in opus could be renamed to opus_pitch_xcorrJean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1962Quality is poorer when the FrameSize is 10 ms2018-11-26T18:44:40ZCedrick FonkwaQuality is poorer when the FrameSize is 10 msRunning PESQ score with OPUS codec show that the quality is not as good with 10ms packet size as with others (20, 40, 60).
Example:
Mean PESQ with 8 kHz - 10000 kbps - 10 ms : 3.19
Mean PESQ with 8 kHz - 10000 kbps - 20 ms : 3.75
Is...Running PESQ score with OPUS codec show that the quality is not as good with 10ms packet size as with others (20, 40, 60).
Example:
Mean PESQ with 8 kHz - 10000 kbps - 10 ms : 3.19
Mean PESQ with 8 kHz - 10000 kbps - 20 ms : 3.75
Is there any reason that could explain this ? Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1968URL incorrect in celt/entdec.c2018-11-26T18:44:40ZTony WilsonURL incorrect in celt/entdec.cThe MMW98 pdf is in .../ee398a/... The MMW98 pdf is in .../ee398a/... Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1978opus_decode fails on >20ms zero-length frame following hybrid frame2018-11-26T18:44:40ZMark Harrisopus_decode fails on >20ms zero-length frame following hybrid frameopus_decode fails with OPUS_BAD_ARG on a packet containing a 40ms or 60ms LP zero-length frame when it follows a hybrid or MDCT frame.
The attached ogg opus file contains ten 40ms packets. The duration of the expected output is 400ms -...opus_decode fails with OPUS_BAD_ARG on a packet containing a 40ms or 60ms LP zero-length frame when it follows a hybrid or MDCT frame.
The attached ogg opus file contains ten 40ms packets. The duration of the expected output is 400ms - 6.5ms pre-skip = 393.5ms. However, opus_decode and the opusdec tool fail after the first packet. The 1.0 reference implementation decodes it successfully.
The first packet contains two 20ms Hybrid SWB frames, and the others each contain one 40ms LP WB frame. The first 40ms LP WB frame has a length of 0, invoking PLC.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1979opus_decode LP PLC fails to accommodate frame size change during packet loss2018-11-26T18:44:40ZMark Harrisopus_decode LP PLC fails to accommodate frame size change during packet lossSuppose opus packets are being received over an unreliable network with a frame size and packet size of 40ms. There is some packet loss, and during that time the sender switches to 10ms packets, as shown below:
Received packets:
|= tim...Suppose opus packets are being received over an unreliable network with a frame size and packet size of 40ms. There is some packet loss, and during that time the sender switches to 10ms packets, as shown below:
Received packets:
|= timestamp =|= content =|
|-------------|------------|
| //t// | 40ms frame |
| //t//+80ms | 10ms frame |
`opus_decode()` is called in the usual manner for the time //t// packet. When the next packet is received for time //t//+80ms, `opus_decode()` is called with that packet using `decode_fec`=1 and `frame_size`=1920 (40ms), to fill in the gap from //t//+40ms to //t//+80ms.
If libopus assertions are enabled, an assertion failure is produced:
```
Fatal (internal) error in silk/dec_API.c, line 142: assertion failed: 0
Abort trap
```
If libopus assertions are disabled it does not abort, but the pcm output contains 30ms of digital silence from //t//+40ms to //t//+70ms before the PLC (or FEC if available) activates. This is shown in the attached picture, in which //t//=0 and the audio is a continuous 880 Hz sine wave with constant amplitude.
It expected that the entire gap from //t//+40ms to //t//+80ms will be filled in with interpolated PLC data and any available FEC data, as it does with no frame size change, without producing an assertion failure.
Note that the same type of failure also occurs for other times and frame sizes, e.g. if the second packet contains a 2.5ms MDCT frame for time //t//+55ms.
The issue can be reproduced by decoding the attached opus_demo bitstream.
```
opus_demo -d 48000 1 -inbandfec opus-lp-plc-fail.opusdemo out.pcm
```Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1980opus_decode undefined behavior decoding FEC from invalid packet2018-11-26T18:44:40ZMark Harrisopus_decode undefined behavior decoding FEC from invalid packetAttempting to decode FEC from an invalid packet can cause the opus decoder to use uninitialized data from the stack, and potentially dereference out-of-bounds memory addresses or crash depending on the contents of the uninitialized data....Attempting to decode FEC from an invalid packet can cause the opus decoder to use uninitialized data from the stack, and potentially dereference out-of-bounds memory addresses or crash depending on the contents of the uninitialized data.
Decoding the attached opus_demo bitstream under valgrind demonstrates the issue.
```
opus_demo -d 48000 1 -inbandfec opus-fec-uninit.opusdemo out.pcm
```Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1981opus_multistream_decode read beyond end of payload2018-11-26T18:44:40ZMark Harrisopus_multistream_decode read beyond end of payloadUp to 2 bytes beyond the end of the payload may be read when decoding a specially-crafted self-delimited code 2 or code 3 vbr multistream packet.Up to 2 bytes beyond the end of the payload may be read when decoding a specially-crafted self-delimited code 2 or code 3 vbr multistream packet.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1984opus_multistream_encoder_ctl(st, OPUS_RESET_STATE) unimplemented2018-11-26T18:44:39ZMark Harrisopus_multistream_encoder_ctl(st, OPUS_RESET_STATE) unimplementedUnder `opus_multistream_encoder_init()`, the [Opus Multistream API](https://mf4.xiph.org/jenkins/view/opus/job/opus/ws/doc/html/group__opus__multistream.html#gae7586aa54c322fd9599de24b5c8b8c01) documentation states:
> To reset a previou...Under `opus_multistream_encoder_init()`, the [Opus Multistream API](https://mf4.xiph.org/jenkins/view/opus/job/opus/ws/doc/html/group__opus__multistream.html#gae7586aa54c322fd9599de24b5c8b8c01) documentation states:
> To reset a previously initialized state, use the `OPUS_RESET_STATE` CTL.
However, `opus_multistream_encoder_ctl(st, OPUS_RESET_STATE)` returns `OPUS_UNIMPLEMENTED`.
Workaround: Destroy encoder and create a new one.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/2317Make usage tracking switchable!2018-11-20T16:57:36ZSven JörnsMake usage tracking switchable!I'm not quite sure if it's true, but in the README from Asterisk
(http://downloads.digium.com/pub/telephony/codec_opus/asterisk-13.0/x86-64/README) states that the Opus codec always sends anonymous usage data to an Asterisk community se...I'm not quite sure if it's true, but in the README from Asterisk
(http://downloads.digium.com/pub/telephony/codec_opus/asterisk-13.0/x86-64/README) states that the Opus codec always sends anonymous usage data to an Asterisk community server.
In the times of the European data protection regulation this is an avoidable problem.
Therefore, the usage tracking should at least be switchable off.https://gitlab.xiph.org/xiph/opus/-/issues/2316Assert in celt_decoder when custom modes are disabled2018-10-12T10:17:30ZPhilippe NormandAssert in celt_decoder when custom modes are disabledI can't reproduce this issue outside of WebKit unfortunately. With a libopus built with `--enable-custom-modes=no`, open a youtube video (make sure MediaSource webkit websetting is turned on).
```
Fatal (internal) error in /home/phil/We...I can't reproduce this issue outside of WebKit unfortunately. With a libopus built with `--enable-custom-modes=no`, open a youtube video (make sure MediaSource webkit websetting is turned on).
```
Fatal (internal) error in /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/celt/celt_decoder.c, line 118: assertion failed: st->mode == opus_custom_mode_create(48000, 960, NULL)
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f54bd4e82f1 in __GI_abort () at abort.c:79
#2 0x00007f545143e81f in celt_fatal () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/celt/arch.h:76
#3 0x00007f5451446a65 in validate_celt_decoder () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/celt/celt_decoder.c:118
#4 0x00007f5451446b84 in celt_decode_with_ec () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/celt/celt_decoder.c:867
#5 0x00007f545146d7bf in opus_decode_frame () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/src/opus_decoder.c:518
#6 0x00007f545146eb16 in opus_decode_native () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/src/opus_decoder.c:721
#7 0x00007f545147810a in opus_multistream_decode_native () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/src/opus_multistream_decoder.c:253
#8 0x00007f54514784b9 in opus_multistream_decode () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/src/opus_multistream_decoder.c:398
#9 0x00007f545275c134 in opus_dec_chain_parse_data () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.14.4/ext/opus/gstopusdec.c:630
#10 0x00007f545275d5b3 in gst_opus_dec_handle_frame () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.14.4/ext/opus/gstopusdec.c:908
#11 0x00007f54bf915dc9 in gst_audio_decoder_push_buffers () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.14.4/gst-libs/gst/audio/gstaudiodecoder.c:1540
#12 0x00007f54bf91615b in gst_audio_decoder_chain_forward () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.14.4/gst-libs/gst/audio/gstaudiodecoder.c:1654
#13 0x00007f54bf917377 in gst_audio_decoder_chain () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.14.4/gst-libs/gst/audio/gstaudiodecoder.c:1914
#14 0x00007f54bfa0daba in gst_pad_chain_data_unchecked () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4322
#15 gst_pad_push_data () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4578
#16 0x00007f54bfa15c32 in gst_pad_push () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4697
#17 0x00007f54bfa0daba in gst_pad_chain_data_unchecked () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4322
#18 gst_pad_push_data () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4578
#19 0x00007f54bfa15c32 in gst_pad_push () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4697
#20 0x00007f54bf9fbcbb in gst_proxy_pad_chain_default () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstghostpad.c:127
#21 0x00007f54bfa0daba in gst_pad_chain_data_unchecked () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4322
#22 gst_pad_push_data () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4578
#23 0x00007f54bfa15c32 in gst_pad_push () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4697
#24 0x00007f54bf9fbcbb in gst_proxy_pad_chain_default () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstghostpad.c:127
#25 0x00007f54c69d892b in webkitMediaSrcChain(_GstPad*, _GstObject*, _GstBuffer*) () from /home/phil/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37
#26 0x00007f54bfa0daba in gst_pad_chain_data_unchecked () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4322
#27 gst_pad_push_data () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4578
#28 0x00007f54bfa15c32 in gst_pad_push () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4697
#29 0x00007f54bfb13485 in gst_base_src_loop () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/libs/gst/base/gstbasesrc.c:2957
#30 0x00007f54bfa41cb1 in gst_task_func () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gsttask.c:332
#31 0x00007f54beb78933 in g_thread_pool_thread_proxy () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/glib-2.54.2/glib/gthreadpool.c:307
#32 0x00007f54beb77fd5 in g_thread_proxy () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/glib-2.54.2/glib/gthread.c:784
#33 0x00007f54c06edf2a in start_thread (arg=0x7f54537fe700) at pthread_create.c:463
#34 0x00007f54bd5a8edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
I don't understand this assert, pointer comparison doesn't make much sense to me in this context.