Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2018-10-27T17:00:55Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2341Improvements to auth_result and it's usage (more and better results)2018-10-27T17:00:55ZPhilipp SchafftImprovements to auth_result and it's usage (more and better results)The enum auth_result currently implements:
* "undefined": The code comments this as "XXX: ???",
* "ok": client passed the auth backend successfully,
* "failed": client did not pass (because of invalid credentials or because of backend ma...The enum auth_result currently implements:
* "undefined": The code comments this as "XXX: ???",
* "ok": client passed the auth backend successfully,
* "failed": client did not pass (because of invalid credentials or because of backend malfunction),
* "released": used internally for on-disconnect handlers,
* "forbidden": unused,
* "no match": client is unknown to this backend,
* "user added", "user exists", "user deleted": used by management functions.
I suggest to change this the following way:
* Make "forbidden" settable by auth backends for permanent no-passes. This would terminate any auth retry. It could be useful for when the client *IS* identified (credentials match) but the backend forbids access (user has been banned, access has been terminated, ...).
* Add "backend failed" that indicates a problem with the backend, not the credentials. Such failures would include non-responsive backend servers (e.g. with URL auth) or misconfiguration (e.g. invalid file for htpasswd auth).
* Add a "user modified" for management functions as the current set does not allow updating users (only delete-then-add-again patterns).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/liboggz/-/issues/6assertion failure in oggz_close at oggz.c:218 when scanning corrupted file2018-08-08T17:46:51Zkeelerdaassertion failure in oggz_close at oggz.c:218 when scanning corrupted fileoggz-scan exits with "Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed." when scanning a corrupted file.oggz-scan exits with "Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed." when scanning a corrupted file.conradconradhttps://gitlab.xiph.org/xiph/liboggz/-/issues/5[liboggz] oggz-info reports incorrect duration for chained files2018-08-08T17:46:39ZGArik[liboggz] oggz-info reports incorrect duration for chained filesHi, all
I have:
libvorbis-1.2.3
vorbis-tools-1.2.0
libogg-1.1.4
liboggz-0.9.9 installed on my system.
The problem is that oggz-info unable to detect "Content-Duration" correctly. As the result "Content-Bitrate-Average" is also incorrec...Hi, all
I have:
libvorbis-1.2.3
vorbis-tools-1.2.0
libogg-1.1.4
liboggz-0.9.9 installed on my system.
The problem is that oggz-info unable to detect "Content-Duration" correctly. As the result "Content-Bitrate-Average" is also incorrect. Also slightly different bitrate detection by ogginfo and oggz-info seems strange to me.
Here is an example:
```
lxuser@garik:~/oggz-bug$ ls
test0.ogg test1.ogg
lxuser@garik:~/oggz-bug$ LANG=C ogginfo *.ogg
Processing file "test0.ogg"...
New logical stream (#1, serial: 7f1f032f): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 1984900 bytes
Playback length: 0m:55.546s
Average bitrate: 285.871339 kb/s
Logical stream 1 ended
Processing file "test1.ogg"...
New logical stream (#1, serial: 7f1f0330): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 10962852 bytes
Playback length: 4m:07.520s
Average bitrate: 354.326180 kb/s
Logical stream 1 ended
lxuser@garik:~/oggz-bug$ oggz-info -a *.ogg
Filename: test0.ogg
Content-Duration: 00:00:55.546
Content-Length: 1.897 MB
Content-Bitrate-Average: 286.452 kbps
Vorbis: serialno 2132738863
4617 packets in 467 pages, 9.9 packets/page, 1.098% Ogg overhead
Content-Length: 1.897 MB
Content-Bitrate-Average: 286.452 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.302 kB
Page-Length-StdDev: 230 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 304 bytes
------------------------------------------------------------
Filename: test1.ogg
Content-Duration: 00:04:07.520
Content-Length: 10.459 MB
Content-Bitrate-Average: 354.455 kbps
Vorbis: serialno 2132738864
30765 packets in 2577 pages, 11.9 packets/page, 1.116% Ogg overhead
Content-Length: 10.459 MB
Content-Bitrate-Average: 354.455 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.297 kB
Page-Length-StdDev: 111 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 298 bytes
lxuser@garik:~/oggz-bug$ cat test0.ogg test1.ogg > test.ogg
lxuser@garik:~/oggz-bug$ LANG=C ogginfo test.ogg
Processing file "test.ogg"...
New logical stream (#1, serial: 7f1f032f): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 1984900 bytes
Playback length: 0m:55.546s
Average bitrate: 285.871339 kb/s
Logical stream 1 ended
New logical stream (#2, serial: 7f1f0330): type vorbis
Vorbis headers parsed for stream 2, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 2:
Total data length: 10962852 bytes
Playback length: 4m:07.520s
Average bitrate: 354.326180 kb/s
Logical stream 2 ended
lxuser@garik:~/oggz-bug$ oggz-info -a test.ogg
Content-Duration: 00:04:07.520
Content-Length: 12.356 MB
Content-Bitrate-Average: 418.738 kbps
Vorbis: serialno 2132738863
4617 packets in 467 pages, 9.9 packets/page, 1.098% Ogg overhead
Content-Length: 1.897 MB
Content-Bitrate-Average: 64.282 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.302 kB
Page-Length-StdDev: 230 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 304 bytes
Vorbis: serialno 2132738864
30765 packets in 2577 pages, 11.9 packets/page, 1.116% Ogg overhead
Content-Length: 10.459 MB
Content-Bitrate-Average: 354.455 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.297 kB
Page-Length-StdDev: 111 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 298 bytes
```conradconradhttps://gitlab.xiph.org/xiph/liboggz/-/issues/4[liboggz] oggz-diff unable to process files with whitespace in filename2018-08-08T17:45:36ZGArik[liboggz] oggz-diff unable to process files with whitespace in filenameoggz-diff unable to process files with whitespace in filename.
liboggz compiled from trunk on 21.08.2009 (yesterday)oggz-diff unable to process files with whitespace in filename.
liboggz compiled from trunk on 21.08.2009 (yesterday)Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/liboggz/-/issues/3Buffer overflow in liboggz, httpdate.c, function httpdate_parse2018-08-08T17:44:41ZhannoBuffer overflow in liboggz, httpdate.c, function httpdate_parseThe function httpdate_parse writes 4 bytes to the three byte variables wday and month. These are supposed to store a 3 byte string, however that misses that the string needs a null terminating byte. Making the variables 4 bytes fixes thi...The function httpdate_parse writes 4 bytes to the three byte variables wday and month. These are supposed to store a 3 byte string, however that misses that the string needs a null terminating byte. Making the variables 4 bytes fixes this.
Also the parser string should limit the size of the month string. See attached patch.
This bug was found with the help of address sanitizer. Can be reproduced by compiling liboggz with -fsanitize=address in CFLAGS+LDFLAGS and running make check.Monty MontgomeryMonty Montgomeryhttps://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/icecast-server/-/issues/2333Make playlist generation consistent2020-10-11T16:28:01ZMarvin ScholzMake playlist generation consistentCurrently all playlist formats are generated using XSLT, but m3u is generated in C code. This should be done consistent, either all as XSLT or all in C code.
Opinions which way will be better welcome!Currently all playlist formats are generated using XSLT, but m3u is generated in C code. This should be done consistent, either all as XSLT or all in C code.
Opinions which way will be better welcome!https://gitlab.xiph.org/xiph/theora/-/issues/2310Gentoo QA issue with decode.c2018-06-22T17:45:59ZGhost UserGentoo QA issue with decode.cMy GNU/Linux distribution is Gentoo Linux. When installing `media-libs/libtheora-1.1.1-r1` with the Portage package manager I get the following warning message:
```
* QA Notice: Package triggers severe warnings which indicate that it
...My GNU/Linux distribution is Gentoo Linux. When installing `media-libs/libtheora-1.1.1-r1` with the Portage package manager I get the following warning message:
```
* QA Notice: Package triggers severe warnings which indicate that it
* may exhibit random runtime failures.
* /var/tmp/portage/media-libs/libtheora-1.1.1-r1/work/libtheora-1.1.1/lib/decode.c:400:49: warning: iteration 2 invokes undefined behavior [-Waggressive-loop-optimizations]
* Please do not file a Gentoo bug and instead report the above QA
* issues directly to the upstream developers of this software.
* Homepage: https://www.theora.org
```
[build.log.xz](/uploads/fee915344d8156b954b6310b01b7e0e1/build.log.xz)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2330Segmentation Fault in auth.c2018-04-18T00:14:17ZMarvin ScholzSegmentation Fault in auth.cReported by hopejr on Github:
There is a seg fault on unlocking the thread on line 189 of auth.c in the function auth_release() under certain circumstances:
1. Configure a mount point with a fallback that is a relay from another server...Reported by hopejr on Github:
There is a seg fault on unlocking the thread on line 189 of auth.c in the function auth_release() under certain circumstances:
1. Configure a mount point with a fallback that is a relay from another server that is actually running (the stream must have parameter hidden=0 and fallback-override=1)
2. Start Icecast
3. Stream to Icecast, and then stop the stream after an arbitrary amount of time
4. Load the status page in the browser
At that point, there will be a seg fault as described above. It does not happen when the mount point is hidden for some reason.
Test system is running Debian 9.3. Icecast version 2.4.99.2https://gitlab.xiph.org/xiph/rav1e/-/issues/84Add integration tests2018-02-28T19:58:31ZThomas DaedeAdd integration tests*Created by: yushincho*
That is another lovely built-in feature of Rust. Let's use it asap, and not writing hassle separate unit-tests programs.*Created by: yushincho*
That is another lovely built-in feature of Rust. Let's use it asap, and not writing hassle separate unit-tests programs.https://gitlab.xiph.org/xiph/rav1e/-/issues/83Warnings with "cargo bench"2018-02-28T19:58:32ZThomas DaedeWarnings with "cargo bench"*Created by: yushincho*
yushin@maui:~/workspace/rav1e$ cargo test
Compiling bitstream-io v0.6.3
Compiling bitflags v1.0.1
Compiling bencher v0.1.5
Compiling bitflags v0.4.0
Compiling encode_unicode v0.1.3
Compili...*Created by: yushincho*
yushin@maui:~/workspace/rav1e$ cargo test
Compiling bitstream-io v0.6.3
Compiling bitflags v1.0.1
Compiling bencher v0.1.5
Compiling bitflags v0.4.0
Compiling encode_unicode v0.1.3
Compiling vec_map v0.8.0
Compiling unicode-width v0.1.4
Compiling ansi_term v0.10.2
Compiling y4m v0.1.1
Compiling byteorder v1.2.1
Compiling libc v0.2.36
Compiling strsim v0.7.0
Compiling textwrap v0.9.0
Compiling nix v0.5.1
Compiling atty v0.2.6
Compiling rand v0.4.2
Compiling clap v2.30.0
Compiling rustyline v1.0.0
Compiling rav1e v0.1.0 (file:///home/yushin/workspace/rav1e)
Finished dev [unoptimized + debuginfo] target(s) in 9.73 secs
Running target/debug/deps/rav1e-9b00cc822757fb1d
running 6 tests
test ec::test::booleans ... ok
test ec::test::cdf ... ok
test ec::test::mixed ... ok
test predict::test::pred_max ... ok
test predict::test::pred_same ... ok
test predict::test::pred_matches ... ok
test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
Running target/debug/deps/rav1e-5895d273f770ce9f
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
Running target/debug/deps/rav1repl-81dcf9202be56248
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
Doc-tests rav1e
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
yushin@maui:~/workspace/rav1e$ cargo bench
Compiling bencher v0.1.5
Compiling rav1e v0.1.0 (file:///home/yushin/workspace/rav1e)
warning: unused import: `rav1e::predict::*;`
--> benches/bench.rs:95:5
|
95 | use rav1e::predict::*;
| ^^^^^^^^^^^^^^^^^^
|
= note: #[warn(unused_imports)] on by default
warning: unused variable: `mode`
--> benches/bench.rs:111:9
|
111 | let mode = PredictionMode::DC_PRED;
| ^^^^
|
= note: #[warn(unused_variables)] on by default
= note: to avoid this warning, consider using `_mode` instead
warning: foreign function is never used: `highbd_dc_left_predictor`
--> benches/bench.rs:15:5
|
15 | / fn highbd_dc_left_predictor(dst: *mut u16, stride: libc::ptrdiff_t, bw: libc::c_int,
16 | | bh: libc::c_int, above: *const u16,
17 | | left: *const u16, bd: libc::c_int);
| |______________________________________________________________^
|
= note: #[warn(dead_code)] on by default
warning: foreign function is never used: `highbd_dc_top_predictor`
--> benches/bench.rs:18:5
|
18 | / fn highbd_dc_top_predictor(dst: *mut u16, stride: libc::ptrdiff_t, bw: libc::c_int,
19 | | bh: libc::c_int, above: *const u16,
20 | | left: *const u16, bd: libc::c_int);
| |______________________________________________________________^
warning: foreign function is never used: `highbd_h_predictor`
--> benches/bench.rs:21:5
|
21 | / fn highbd_h_predictor(dst: *mut u16, stride: libc::ptrdiff_t, bw: libc::c_int,
22 | | bh: libc::c_int, above: *const u16,
23 | | left: *const u16, bd: libc::c_int);
| |______________________________________________________________^
warning: foreign function is never used: `highbd_v_predictor`
--> benches/bench.rs:24:5
|
24 | / fn highbd_v_predictor(dst: *mut u16, stride: libc::ptrdiff_t, bw: libc::c_int,
25 | | bh: libc::c_int, above: *const u16,
26 | | left: *const u16, bd: libc::c_int);
| |___________________________________________^
warning: function is never used: `pred_h_4x4`
--> benches/bench.rs:37:1
|
37 | fn pred_h_4x4(output: &mut [u16], stride: usize, above: &[u16], left: &[u16]) {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
warning: function is never used: `pred_v_4x4`
--> benches/bench.rs:44:1
|
44 | fn pred_v_4x4(output: &mut [u16], stride: usize, above: &[u16], left: &[u16]) {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Finished release [optimized] target(s) in 3.83 secs
Running target/release/deps/rav1e-c60027f9b9bd002f
running 6 tests
test ec::test::booleans ... ignored
test ec::test::cdf ... ignored
test ec::test::mixed ... ignored
test predict::test::pred_matches ... ignored
test predict::test::pred_max ... ignored
test predict::test::pred_same ... ignored
test result: ok. 0 passed; 0 failed; 6 ignored; 0 measured; 0 filtered out
Running target/release/deps/rav1e-ab1af7a55ae80597
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
Running target/release/deps/rav1repl-b79447a2b246d724
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
Running target/release/deps/bench-741fd4a6e67fa1d0
running 4 tests
test aom ... bench: 1,188,882 ns/iter (+/- 38,736)
test native ... bench: 975,183 ns/iter (+/- 59,961)
test native_trait ... bench: 269,857 ns/iter (+/- 10,470)
test write_b_bench ... bench: 123,071 ns/iter (+/- 6,586)
test result: ok. 0 passed; 0 failed; 0 ignored; 4 measured
yushin@maui:~/workspace/rav1e$
https://gitlab.xiph.org/xiph/rav1e/-/issues/75Would't supporting multithreading at early stage better?2018-02-28T19:58:32ZThomas DaedeWould't supporting multithreading at early stage better?*Created by: yushincho*
Minimum prerequisite is a tiling support.*Created by: yushincho*
Minimum prerequisite is a tiling support.https://gitlab.xiph.org/xiph/rav1e/-/issues/74Support tiling2018-02-28T19:58:32ZThomas DaedeSupport tiling*Created by: yushincho*
*Created by: yushincho*
https://gitlab.xiph.org/xiph/rav1e/-/issues/73A better name?2018-02-28T19:58:32ZMichael BebenitaA better name?rav1e is great and all, but it doesn't quite roll off the tongue. Let's comment on this issue with name ideas, and then vote on them using 👍.rav1e is great and all, but it doesn't quite roll off the tongue. Let's comment on this issue with name ideas, and then vote on them using 👍.https://gitlab.xiph.org/xiph/rav1e/-/issues/72Support chroma sampling other than 4:2:02018-02-28T19:58:32ZThomas DaedeSupport chroma sampling other than 4:2:0*Created by: yushincho*
Would be happy if we can do this by 2020.*Created by: yushincho*
Would be happy if we can do this by 2020.https://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/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/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/OggIndex/-/issues/1OggIndex needs opus support2017-09-25T22:33:09ZGitlab 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.
https://git.xiph.org/?p=OggIndex.git;a=treeRight now one can not use Ogg with Theora and Opus with an index.
As a first step OggIndex needs support for Opus.
https://git.xiph.org/?p=OggIndex.git;a=treehttps://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
```