Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2018-02-28T19:58:32Zhttps://gitlab.xiph.org/xiph/rav1e/-/issues/71Support SB size 128x1282018-02-28T19:58:32ZThomas DaedeSupport SB size 128x128*Created by: yushincho*
This task will need sequence_header_read/write(), if not introduced yet.*Created by: yushincho*
This task will need sequence_header_read/write(), if not introduced yet.https://gitlab.xiph.org/xiph/rav1e/-/issues/67Frames with show_existing_frame are blank in reconstruction2018-02-28T19:58:32ZThomas DaedeFrames with show_existing_frame are blank in reconstruction*Created by: barrbrain*
Since becced10, frames with show_existing_frame set are blank in the reconstruction stream.*Created by: barrbrain*
Since becced10, frames with show_existing_frame set are blank in the reconstruction stream.https://gitlab.xiph.org/xiph/rav1e/-/issues/44Add partition splitting to RDO2018-09-23T17:20:12ZThomas DaedeAdd partition splitting to RDO*Created by: tmatth*
Currently in `encode_tile` for every superblock, we search for the intra mode with the best RD (based on a 64x64 SSE), for PARTITION_NONE. We should extend this search to one-level of split.*Created by: tmatth*
Currently in `encode_tile` for every superblock, we search for the intra mode with the best RD (based on a 64x64 SSE), for PARTITION_NONE. We should extend this search to one-level of split.https://gitlab.xiph.org/xiph/rav1e/-/issues/37Decoded output not cropped for non-integer multiple of SB size input2018-09-23T17:19:02ZThomas DaedeDecoded output not cropped for non-integer multiple of SB size input*Created by: tmatth*
To reproduce, encode akiyo_qcif.y4m. (176x144)
Reconstructed output:
![rec](https://user-images.githubusercontent.com/66862/35865560-d79ed2d6-0b22-11e8-9a1d-2122a8d6b961.png)
Decoded output:
![dec](https://u...*Created by: tmatth*
To reproduce, encode akiyo_qcif.y4m. (176x144)
Reconstructed output:
![rec](https://user-images.githubusercontent.com/66862/35865560-d79ed2d6-0b22-11e8-9a1d-2122a8d6b961.png)
Decoded output:
![dec](https://user-images.githubusercontent.com/66862/35865582-e48b5ea6-0b22-11e8-91a0-25a18e2dde8b.png)
We need to skip non-visible blocks in `write_sb` (done), change the dimensions that we write in `write_uncompressed_header` (done), change how partitions are coded on the edges of the frame (not started), ~~get all sizes of intra-predictors~~ (not needed since we force 4x4 everywhere).https://gitlab.xiph.org/xiph/rav1e/-/issues/31Enable rustfmt checking locally and on Travis-ci2018-02-28T19:58:32ZMichael BebenitaEnable rustfmt checking locally and on Travis-cihttps://gitlab.xiph.org/xiph/rav1e/-/issues/28Figure out why cargo rebuilds everything unnecessarily.2018-02-28T19:58:32ZMichael BebenitaFigure out why cargo rebuilds everything unnecessarily.```
cargo run --bin rav1e --release
Compiling rav1e v0.1.0 (file:///Users/.../Workspace/rav1e)
Finished release [optimized] target(s) in 6.98 secs
Running `target/release/rav1e`
```
7s is too long to wait if the code ...```
cargo run --bin rav1e --release
Compiling rav1e v0.1.0 (file:///Users/.../Workspace/rav1e)
Finished release [optimized] target(s) in 6.98 secs
Running `target/release/rav1e`
```
7s is too long to wait if the code hasn't changed.
https://gitlab.xiph.org/xiph/rav1e/-/issues/13Encoding 720p park_joy results in garbled decode.2018-02-28T19:58:32ZThomas DaedeEncoding 720p park_joy results in garbled decode.*Created by: gnafuthegreat*
I encoded park_joy_420_720p50.y4m, and then decoded it using the specific git checkout of aom listed in the README. It resulted in this (after being piped to ffmpeg to dump PNGs):
https://themayhaks.c...*Created by: gnafuthegreat*
I encoded park_joy_420_720p50.y4m, and then decoded it using the specific git checkout of aom listed in the README. It resulted in this (after being piped to ffmpeg to dump PNGs):
https://themayhaks.com/~gideon/test-av1-png/
IVF file is here (about 88MB):
https://themayhaks.com/~gideon/test.ivf
I'm not sure if this is just a result of me not resizing to 1280x768 before feeding it to rav1e, but it didn't complain and it seems to have converted it to 1280x768 during the encoding process.https://gitlab.xiph.org/xiph/speexdsp/-/issues/1./configure --enable-neon fails on AARCH642023-11-09T05:46:41ZTristan Matthews./configure --enable-neon fails on AARCH64Result:
```
configure: error: No 16 bit type found on this platform!
```
This is probably because configure.ac forces `-march=armv7-a` when `--enable-neon` is given explicitly. Plain old configure works (and detects NEON support) as ex...Result:
```
configure: error: No 16 bit type found on this platform!
```
This is probably because configure.ac forces `-march=armv7-a` when `--enable-neon` is given explicitly. Plain old configure works (and detects NEON support) as expected.https://gitlab.xiph.org/xiph/vorbis/-/issues/2333Infinite loop in _get_prev_page_serial2019-01-28T23:34:17ZStefan LednickyInfinite loop in _get_prev_page_serialWe are using libvorbis 1.3.5 , specifically with Unreal Engine.
We get a rare hang in _get_prev_page_serial. What we see is that _get_next_page returns OV_EOF on ln245 of vorbisfile.c, which then causes us to break out of the inner loop...We are using libvorbis 1.3.5 , specifically with Unreal Engine.
We get a rare hang in _get_prev_page_serial. What we see is that _get_next_page returns OV_EOF on ln245 of vorbisfile.c, which then causes us to break out of the inner loop. The outer loop then seeks back to the beginning, and starts reading again, until we get the OV_EOF again in the inner loop... repeat infinitely.
OV_EOF, and possibly other error codes, should perhaps also return or be somehow handled so that it doesn't result in an infinite loop. I'm also guessing _get_prev_page has the same issue.https://gitlab.xiph.org/xiph/Infrastructure/-/issues/2228Add per ip cooldown to media.xiph.org captcha2020-05-26T03:38:32ZRalph GilesAdd per ip cooldown to media.xiph.org captchaI noticed this week on https://media.xiph.org/ the same ip address managed to download *through the captcha* the same 89G file 11 times in the same day. That's counting complete transfers, not the POST request or a handful of truncated o...I noticed this week on https://media.xiph.org/ the same ip address managed to download *through the captcha* the same 89G file 11 times in the same day. That's counting complete transfers, not the POST request or a handful of truncated or Range-request downloads.
If possible, I'd like to add a filter to block repeated downloads. Ideally one download per file per ip address, but something less specific would be helpful too. That seems to best way to limit waste like this without slowing down people who actually need multiple resources.Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2328When configuration file is invalid, icecast hangs indefinitely2018-06-16T20:30:29ZMarcin LewandowskiWhen configuration file is invalid, icecast hangs indefinitelyI am running icecast 2.4.3 on ubuntu 16.04, compiled from sources.
I have found out that if given XML config has invalid syntax, it outputs error but do not terminate the process. It is quite painful as it is not easily possible to chec...I am running icecast 2.4.3 on ubuntu 16.04, compiled from sources.
I have found out that if given XML config has invalid syntax, it outputs error but do not terminate the process. It is quite painful as it is not easily possible to check if service is running or not, as process exists.
```
/usr/bin/icecast -c /etc/icecast/icecast.xml
/etc/icecast/icecast.xml:1: parser error : Document is empty
FATAL: error parsing config file (/etc/icecast/icecast.xml)
XML config parsing error
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/23272.4.99.1 leaks filedescriptors?2020-02-25T08:58:43ZHugo2.4.99.1 leaks filedescriptors?Hi,
We've upgraded some of our production icecast servers to 2.4.99.1 this morning (from 2.4.2, because of the better TLS support). 1 one the 8 upgraded servers is expierencing problems which seem to be known as a "filedescriptor leak"....Hi,
We've upgraded some of our production icecast servers to 2.4.99.1 this morning (from 2.4.2, because of the better TLS support). 1 one the 8 upgraded servers is expierencing problems which seem to be known as a "filedescriptor leak". The server does not respond to new connections anymore, but seems to handle a lot of existing connections still fine. With netstat and lsof a lot of CLOSE_WAIT connections show up:
$ sudo lsof -np 28035 | wc -l
12895
$ sudo lsof -np 28035 | grep CLOSE_WAIT | wc -l
5973
The other 7 servers do not experience this problem (yet). The maximum amount of listeners today was about 6500 per server (on a number of channels).
Could it be that icecast is leaking filedescriptors somehow in situations that are not always triggered (since not all servers encounter this problem)?
All servers are running the same kernel; 4.1.39 and the installation is identical on all systems.
Any suggestions what could be done to debug this problem? It would be nice if we could reproduce this, but I have no clue what could cause this.
Regards,
Hugohttps://gitlab.xiph.org/xiph/liboggz/-/issues/1Granulepos corruption with large/numerous packets (with test case)2018-08-08T17:39:26ZstenyakGranulepos corruption with large/numerous packets (with test case)I'm having issues when dealing with oggz streams that have certain amount of packets and/or certain packet size.
I have attached a test case.
I have reproduced the problem with:
- msvs2015 compiler
- both 32 and 64 bit
- both libog...I'm having issues when dealing with oggz streams that have certain amount of packets and/or certain packet size.
I have attached a test case.
I have reproduced the problem with:
- msvs2015 compiler
- both 32 and 64 bit
- both liboggz v1.1.1 (git `70b58a45`, from 2010-04-29) and the head of master (git `f49574ed` from 2014-04-24). Repo URL: https://git.xiph.org/liboggz.git
In the attached test case, the file writing phase seems to go OK, at least no errors are returned anywhere.
[main.cpp](/uploads/f6ad965f431dd89127c12fadeddfa357/main.cpp)
The writer code is based on the example found here: https://xiph.org/oggz/doc/group__force__feed.html#details
The reading phase is more problematic:
- Passing the file through oggz-validate.exe (as downloaded from https://xiph.org/oggz ) crashes with an Out of Memory error
- Using oggz-dump.exe instead, it seems to read all packets correctly, and output the expected granule positions
- The attached source code is unable to finish without errors though.
To verify the problem, follow these steps:
1. Compile the code as-is, in debug mode (to run all asserts). Everything should go ok. The resulting file `foo.oggz` will be around 160 megs.
2. Set `FAIL = true`, compile and run. An assert will fail, around packet #491. The granule position is corrupted now.
3. Decrease packetSize 1 byte (setting it to `packetSize = 163388`), compile and run. Granule position will be okay again, all asserts will pass.
So it seems that both amount of packets and size of packets can contribute to the corrupted granulepos.
If you need any help reproducing the issue, please let me know.https://gitlab.xiph.org/xiph/ogg/-/issues/2292Granulepos corruption with large/numerous packets (with test case)2018-08-08T17:39:26ZstenyakGranulepos corruption with large/numerous packets (with test case)I'm having issues when dealing with oggz streams that have certain amount of packets and/or certain packet size.
I have attached a test case.
I have reproduced the problem with:
- msvs2015 compiler
- both 32 and 64 bit
- both libog...I'm having issues when dealing with oggz streams that have certain amount of packets and/or certain packet size.
I have attached a test case.
I have reproduced the problem with:
- msvs2015 compiler
- both 32 and 64 bit
- both liboggz v1.1.1 (git `70b58a45`, from 2010-04-29) and the head of master (git `f49574ed` from 2014-04-24). Repo URL: https://git.xiph.org/liboggz.git
In the attached test case, the file writing phase seems to go OK, at least no errors are returned anywhere.
[main.cpp](/uploads/466511c90df23933511eeb891b507af7/main.cpp)
The writer code is based on the example found here: https://xiph.org/oggz/doc/group__force__feed.html#details
The reading phase is more problematic:
- Passing the file through oggz-validate.exe (as downloaded from https://xiph.org/oggz ) crashes with an Out of Memory error
- Using oggz-dump.exe instead, it seems to read all packets correctly, and output the expected granule positions
- The attached source code is unable to finish without errors though.
To verify the problem, follow these steps:
1. Compile the code as-is, in debug mode (to run all asserts). Everything should go ok. The resulting file `foo.oggz` will be around 160 megs.
2. Set `FAIL = true`, compile and run. An assert will fail, around packet #491. The granule position is corrupted now.
3. Decrease packetSize 1 byte (setting it to `packetSize = 163388`), compile and run. Granule position will be okay again, all asserts will pass.
So it seems that both amount of packets and size of packets can contribute to the corrupted granulepos.
If you need any help reproducing the issue, please let me know.https://gitlab.xiph.org/xiph/vorbis/-/issues/2332CVE-2017-11333 - The vorbis_analysis_wrote function in lib/block.c in Xiph.Or...2018-03-17T18:07:32ZGuido GüntherCVE-2017-11333 - The vorbis_analysis_wrote function in lib/block.c in Xiph.Org libvorbis 1.3.5 allows remote attackers to cause a denial of service (OOM) via a crafted wav file.Discovered by qflb.wu
See 2nd issue in http://seclists.org/fulldisclosure/2017/Jul/82
Copy paste from there:
```
1.
the vorbis_analysis_wrote function in lib/block.c in Xiph.Org libvorbis 1.3.5 can cause a denial of service(OOM) via a ...Discovered by qflb.wu
See 2nd issue in http://seclists.org/fulldisclosure/2017/Jul/82
Copy paste from there:
```
1.
the vorbis_analysis_wrote function in lib/block.c in Xiph.Org libvorbis 1.3.5 can cause a denial of service(OOM) via a
crafted wav file.
I found this bug when I test Sound eXchange(SoX) 14.4.2 which used the libvorbis library.
./sox libvorbis_1.3.5_OOM.wav out.ogg
/var/log/syslog info:
Jul 13 19:58:05 ubuntu kernel: [] Out of memory: Kill process 44203 (sox) score 364 or sacrifice child
Jul 13 19:58:05 ubuntu kernel: [] Killed process 44203 (sox) total-vm:1831804kB, anon-rss:599932kB, file-rss:40kB
----debug info:----
#0 0x00007ffff5df5e92 in vorbis_analysis_wrote ()
from /usr/local/lib/libvorbis.so.0
#1 0x00007ffff7ba1cba in write_samples (ft=0x611c20, buf=buf@entry=0x0,
len=len@entry=0x0) at vorbis.c:358
#2 0x00007ffff7ba1dc5 in stopwrite (ft=<optimized out>) at vorbis.c:398
#3 0x00007ffff7b58488 in sox_close (ft=0x611c20) at formats.c:1006
#4 0x0000000000405fa8 in cleanup () at sox.c:246
#5 0x0000000000403479 in main (argc=argc@entry=0x3,
argv=argv@entry=0x7fffffffe5e8) at sox.c:3050
#6 0x00007ffff727bec5 in __libc_start_main (main=0x4029c0 <main>, argc=0x3,
argv=0x7fffffffe5e8, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffe5d8) at libc-start.c:287
#7 0x0000000000403c65 in _start ()
--------
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
```https://gitlab.xiph.org/xiph/vorbis/-/issues/2331CVE-2017-11735 - The vorbis_block_clear function in lib/block.c in Xiph.Org l...2017-10-09T06:14:10ZGuido GüntherCVE-2017-11735 - The vorbis_block_clear function in lib/block.c in Xiph.Org libvorbis 1.3.5 allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted ogg file.Discovered by qflb.wu
See 2nd issue in http://seclists.org/fulldisclosure/2017/Jul/82
Copy paste from there:
```
2.
the vorbis_block_clear function in lib/block.c in Xiph.Org libvorbis 1.3.5 can cause a denial of service(NULL pointer ...Discovered by qflb.wu
See 2nd issue in http://seclists.org/fulldisclosure/2017/Jul/82
Copy paste from there:
```
2.
the vorbis_block_clear function in lib/block.c in Xiph.Org libvorbis 1.3.5 can cause a denial of service(NULL pointer
dereference and application crash) via a crafted ogg file.
I found this bug when I test mp3splt 2.6.2 which used the libvorbis library.
./mp3splt -P -t 0.9 libvorbis_1.3.5_null_pointer_dereference.ogg
----debug info:----
0x00007ffff61752c0 in vorbis_block_clear () from /usr/local/lib/libvorbis.so.0
(gdb) disassemble
Dump of assembler code for function vorbis_block_clear:
0x00007ffff61752a0 <+0>:push %r14
0x00007ffff61752a2 <+2>:mov %rdi,%r14
0x00007ffff61752a5 <+5>:push %r13
0x00007ffff61752a7 <+7>:push %r12
0x00007ffff61752a9 <+9>:push %rbp
0x00007ffff61752aa <+10>:push %rbx
0x00007ffff61752ab <+11>:mov 0xb8(%rdi),%r13
0x00007ffff61752b2 <+18>:callq 0x7ffff616b240 <_vorbis_block_ripcord@plt>
0x00007ffff61752b7 <+23>:mov 0x70(%r14),%rdi
0x00007ffff61752bb <+27>:test %rdi,%rdi
0x00007ffff61752be <+30>:je 0x7ffff61752c5 <vorbis_block_clear+37>
=> 0x00007ffff61752c0 <+32>:callq 0x7ffff616b130 <free@plt>
0x00007ffff61752c5 <+37>:test %r13,%r13
0x00007ffff61752c8 <+40>:je 0x7ffff617530c <vorbis_block_clear+108>
0x00007ffff61752ca <+42>:mov $0x1,%r12d
0x00007ffff61752d0 <+48>:xor %ebx,%ebx
0x00007ffff61752d2 <+50>:jmp 0x7ffff61752df <vorbis_block_clear+63>
0x00007ffff61752d4 <+52>:nopl 0x0(%rax)
0x00007ffff61752d8 <+56>:add $0x1,%ebx
0x00007ffff61752db <+59>:add $0x1,%r12d
0x00007ffff61752df <+63>:movslq %ebx,%rax
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) i r
rax 0x22
rbx 0x61fca06421664
rcx 0x00
rdx 0x7ffff7ba6778140737349576568
rsi 0x00
rdi 0x80128
rbp 0x7fffffffd4700x7fffffffd470
rsp 0x7fffffffd4000x7fffffffd400
r8 0x746e656d75636f008389754676633104128
r9 0x6143506374224
r10 0x7fffffffd1f0140737488343536
r11 0x7ffff61752a0140737322111648
r12 0x6128506367312
r13 0x00
r14 0x6205606423904
r15 0x7ffff7bcf146140737349742918
rip 0x7ffff61752c00x7ffff61752c0 <vorbis_block_clear+32>
eflags 0x202[ IF ]
cs 0x3351
ss 0x2b43
ds 0x00
es 0x00
fs 0x00
---Type <return> to continue, or q <return> to quit---
gs 0x00
(gdb) ni
Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x80) at malloc.c:2929
2929malloc.c: No such file or directory.
(gdb) bt
#0 __GI___libc_free (mem=0x80) at malloc.c:2929
#1 0x00007ffff61752c5 in vorbis_block_clear ()
from /usr/local/lib/libvorbis.so.0
#2 0x00007ffff65ac5ae in splt_ogg_v_free (oggstate=0x61fca0) at ogg.c:162
#3 0x00007ffff65ace0b in splt_ogg_info (in=<optimized out>,
state=state@entry=0x60ddb0, error=error@entry=0x7fffffffdbf0) at ogg.c:545
#4 0x00007ffff65acf75 in splt_ogg_get_info (state=state@entry=0x60ddb0,
file_input=<optimized out>, error=error@entry=0x7fffffffdbf0) at ogg.c:108
#5 0x00007ffff65ae6c7 in splt_pl_init (state=0x60ddb0, error=0x7fffffffdbf0)
at ogg.c:1482
#6 0x00007ffff7bcac16 in splt_tp_get_original_tags_and_append (
error=0x7fffffffdbf0, state=0x60ddb0) at tags_parser.c:545
#7 splt_tp_process_original_tags_variable (tpu=tpu@entry=0x61f800,
state=state@entry=0x60ddb0, error=error@entry=0x7fffffffdbf0,
set_original_tags=1) at tags_parser.c:514
#8 0x00007ffff7bcb4d1 in splt_tp_process_tag_variable (error=0x7fffffffdbf0,
state=0x60ddb0, tpu=0x61f800, end_paranthesis=0x7ffff7bcf14c "]",
tag_variable_start=0x7ffff7bcf146 "o,@N=1]") at tags_parser.c:363
#9 splt_tp_process_tags (error=0x7fffffffdbf0, state=0x60ddb0, tpu=0x61f800,
tags=0x7ffff7bcf143 "%[@o,@N=1]") at tags_parser.c:293
#10 splt_tp_put_tags_from_string (state=state@entry=0x60ddb0,
tags=tags@entry=0x7ffff7bcf143 "%[@o,@N=1]",
error=error@entry=0x7fffffffdbf0) at tags_parser.c:192
---Type <return> to continue, or q <return> to quit---
#11 0x00007ffff7bbb4f3 in mp3splt_split (state=state@entry=0x60ddb0)
at mp3splt.c:1232
#12 0x0000000000403320 in main (argc=<optimized out>,
orig_argv=<optimized out>) at mp3splt.c:872
(gdb)
--------------------
int vorbis_block_clear(vorbis_block *vb){
int i;
vorbis_block_internal *vbi=vb->internal;
_vorbis_block_ripcord(vb);
if(vb->localstore)_ogg_free(vb->localstore); <========
if(vbi){
for(i=0;i<PACKETBLOBS;i++){
oggpack_writeclear(vbi->packetblob[i]);
if(i!=PACKETBLOBS/2)_ogg_free(vbi->packetblob[i]);
}
_ogg_free(vbi);
}
memset(vb,0,sizeof(*vb));
return(0);
}
```https://gitlab.xiph.org/xiph/rav1e/-/issues/4Support --help2018-02-28T19:58:32ZThomas DaedeSupport --help*Created by: smarter*
Right now, `cargo run` or `cargo run -- --help` panics.*Created by: smarter*
Right now, `cargo run` or `cargo run -- --help` panics.https://gitlab.xiph.org/xiph/rav1e/-/issues/3Add a mode to test encode/decode mismatch2018-02-28T19:58:32ZThomas DaedeAdd a mode to test encode/decode mismatch*Created by: smarter*
Probably by relying on aomdec being on the PATH*Created by: smarter*
Probably by relying on aomdec being on the PATHhttps://gitlab.xiph.org/xiph/rav1e/-/issues/2Setup Travis for CI2019-11-23T11:07:57ZThomas DaedeSetup Travis for CI*Created by: smarter*
https://docs.travis-ci.com/user/languages/rust/*Created by: smarter*
https://docs.travis-ci.com/user/languages/rust/https://gitlab.xiph.org/xiph/theora/-/issues/2305a div zero vul in function fetch_and_process_audio() in libtheora 1.1.12017-09-14T09:24:23ZJiangxina div zero vul in function fetch_and_process_audio() in libtheora 1.1.1```
╭─root@linux-jiangxin in /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples
╰$ gdb encoder_example
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http:...```
╭─root@linux-jiangxin in /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples
╰$ gdb encoder_example
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from encoder_example...done.
(gdb) run ../fuzz/out/Master2/crashes/id:000000,sig:08,src:000000,op:flip1,pos:22 xxx.y4m
Compressing.... pgl쭌躲£¿K+y*ªFၑﲘ።ڗܙ䆾V䔍ᤆ"h1^E³¯¹3⛟䪩Rp¨푳meɆ
/
Program received signal SIGFPE, Arithmetic exception.
fetch_and_process_audio (audio=0x83b010, audiopage=audiopage@entry=0x7fffffffda10, vo=vo@entry=0x7fffffffde10, vd=vd@entry=0x7fffffffdb20, vb=vb@entry=0x7fffffffdbb0, audioflag=audioflag@entry=0) at encoder_example.c:947
947 int toread=4096/2/audio_ch;
(gdb) bt
#0 fetch_and_process_audio (audio=0x83b010, audiopage=audiopage@entry=0x7fffffffda10, vo=vo@entry=0x7fffffffde10, vd=vd@entry=0x7fffffffdb20, vb=vb@entry=0x7fffffffdbb0, audioflag=audioflag@entry=0) at encoder_example.c:947
#1 0x0000000000405a9b in main (argc=<optimized out>, argv=<optimized out>) at encoder_example.c:1754
(gdb) p audio_ch
$1 = 0
```