Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2021-01-04T20:47:54Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2404Issues in log file dublicate items since start of 20212021-01-04T20:47:54ZHans-Georg AlthoffIssues in log file dublicate items since start of 2021I have figured out, that user access is repeating the same data several times since the beginning of the year.
Usual the lines are ordered by time. Now I can see, that ip adresses are repeating with the same date and time.
This is corr...I have figured out, that user access is repeating the same data several times since the beginning of the year.
Usual the lines are ordered by time. Now I can see, that ip adresses are repeating with the same date and time.
This is corrupting my programm[access.log.old](/uploads/10f05b8ae9d6960d4a921d4654ab6e9c/access.log.old), which I use to analyse the data.https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2289ogg123 prints base64 representation of embedded artwork2021-01-04T12:02:59ZDavid Griffithogg123 prints base64 representation of embedded artworkWhen using ogg123 to play an ogg file (perhaps others), it prints hundreds of lines of base64 data to the terminal if the file contains embedded artwork with the description "Metadata_block_picture:" Is this really necessary to print al...When using ogg123 to play an ogg file (perhaps others), it prints hundreds of lines of base64 data to the terminal if the file contains embedded artwork with the description "Metadata_block_picture:" Is this really necessary to print all that by default or at all? If someone wants to use this information, I would think that he/she would use a more convenient way to get at it.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2264vcut segmentation fault2020-12-21T17:25:24ZMartin Steghöfervcut segmentation faultI am forwarding [Debian-bug 818037](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818037) from user Frank Heckenbach <f.heckenbach@fh-soft.de>. Original bug report:
```
Sorry for the brief description, but for what I can tell, that'...I am forwarding [Debian-bug 818037](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818037) from user Frank Heckenbach <f.heckenbach@fh-soft.de>. Original bug report:
```
Sorry for the brief description, but for what I can tell, that's
really it. I tried various cases, and vcut always seems to just
segfault. Here's one example:
% head -c 500000 /dev/zero | oggenc -Q -r -o 1.ogg -
% vcut 1.ogg 2.ogg 3.ogg +1
Processing: Cutting at 1,000000 seconds
Segmentation fault
Tried on both i386 and amd64.
It did work correctly under squeeze and wheezy.
```
I am going to provide a patch down in the comments.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2321In non-blocking mode login errors are not correctly reported2020-12-19T13:51:45ZPhilipp SchafftIn non-blocking mode login errors are not correctly reportedWhen libshout is configured in non-blocking mode fatal authentication errors are not forwarded correctly to the application. Instead retry is signalled.When libshout is configured in non-blocking mode fatal authentication errors are not forwarded correctly to the application. Instead retry is signalled.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2009segfault when trying to encode trivial raw input2020-12-06T14:48:21Zhannosegfault when trying to encode trivial raw inputI was recently trying to create a trivial vorbis file containing just a bit of silence. I thought feeding oggenc a bit if zeros as raw input should do. So I came up with this command line:
dd if=/dev/zero bs=1 count=1 | oggenc -r - -o ou...I was recently trying to create a trivial vorbis file containing just a bit of silence. I thought feeding oggenc a bit if zeros as raw input should do. So I came up with this command line:
dd if=/dev/zero bs=1 count=1 | oggenc -r - -o out.ogg
However, it segfaults. I tried it on different systems and this does not happen everywhere. My system is a 64 bit Gentoo Linux (vorbis-tools 1.4.0, libvorbis 1.3.4, libogg 1.3.1) on a T61 thinkpad laptop. Tried it on an old acer 32 bit laptop with Ubuntu and the same problem didn't happen.
If you need more info to track it down please ask.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1869String concatenation breaks extraction for translation2020-12-06T12:53:57ZgoeranString concatenation breaks extraction for translationIn the file ogginfo/ogginfo2.c there is this code
```
warn(_("WARNING: Expected frame %" I64FORMAT
", got %" I64FORMAT "\n"),
inf->framenum_expected, framenum);
```
The xgettext tool can't handle that, since it doesn't kn...In the file ogginfo/ogginfo2.c there is this code
```
warn(_("WARNING: Expected frame %" I64FORMAT
", got %" I64FORMAT "\n"),
inf->framenum_expected, framenum);
```
The xgettext tool can't handle that, since it doesn't know what I64FORMAT will become. Only "WARNING: Expected frame %" turns up in the message file. (And that will remain unused; that is not what the argument will be at run time.)
There are a few other similar cases in the same file, search for I64FORMAT.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2214compiler warning on assert in resample.c2020-12-06T12:09:49Zvespertocompiler warning on assert in resample.cHi, while installing vorbis-tools in Gentoo, the following warning is issued by the installer:
```
QA Notice: Package triggers severe warnings which indicate that it may exhibit random runtime failures.
resample.c:177:34: warning:...Hi, while installing vorbis-tools in Gentoo, the following warning is issued by the installer:
```
QA Notice: Package triggers severe warnings which indicate that it may exhibit random runtime failures.
resample.c:177:34: warning: comparison with string literal results in unspecified behavior [-Waddress]
```
This is caused by an assert using == on strings. I've never seen any of the Vorbis code but i assume this warning can be fixed with the attached patch.
oggenc -V reports «oggenc from vorbis-tools 1.4.0» but i didn't find that specific version in the bug submission form.
The system is amd64.
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1770oggdec manpage examples are wrong2020-12-06T10:22:45Zalexcoggdec manpage examples are wrong1. oggdec gives signed pcm by default yet the first two examples that claim to give unsigned pcm have no sign argument.
2. oggdec --raw=1
"oggdec: option '--raw' doesn't allow an argument"1. oggdec gives signed pcm by default yet the first two examples that claim to give unsigned pcm have no sign argument.
2. oggdec --raw=1
"oggdec: option '--raw' doesn't allow an argument"Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/libxspf/-/issues/1212[crash] Interger underflow2020-12-01T17:25:12ZJinho Jung[crash] Interger underflowAffected component(s)
======================
- libxspf project(makeUriString function)
- uriparser project (uriToStringCharsRequiredA function)
Attack vector(s)
================
Adversary sends crafted movie playlist file and victim o...Affected component(s)
======================
- libxspf project(makeUriString function)
- uriparser project (uriToStringCharsRequiredA function)
Attack vector(s)
================
Adversary sends crafted movie playlist file and victim opens it with media player which is using libxspf library (such as VLC player).
Suggested description of the vulnerability for use in the CVE
===============================================================
makeUriString() function from Xspf class trusts the return values (i.e., int* charsRequired) from uriparser library; thus assumes positive value.
However, "uriparser" library's uriToStringCharsRequired() functions returns negative value on crafted URI string such as "http://example.co@" (actually the function should return NULL).
Due to this integer underflow, the code meets crash with heap alloction failure.
* libxspf
```c
XML_Char * makeUriString(UriUri const & uri) {
XML_Char * uriString;
int charsRequired;
if (uriToStringCharsRequired(&uri, &charsRequired) != URI_SUCCESS) {
// the uriparse should have return NULL!
return NULL;
}
charsRequired++;
// negative value are inserted to charsRequired (e.g., 0xffffffffff9e5331)
// allocator error here!
uriString = new XML_Char[charsRequired];
if (uriToString(uriString, &uri, charsRequired, NULL) != URI_SUCCESS) {
delete [] uriString;
return NULL;
}
return uriString;
}
```
Discoverer
===========
Jinho Jung (jinho.jung@gatech.edu, Georgia Institute of Technology)
Reference
=========
N/A
Additional Information
======================
1. PoC:
https://ffs.gtisc.gatech.edu/download/ca3502e783138c47/#WQ_4uRrb_CSkyHvA5fpJMg
2. How to reproduce
we use example application from libxspf
1) find read.cpp file and modify the file name to PoC's
2) compile and run the read program
3. We also report this problem to uriparser project teamhttps://gitlab.xiph.org/xiph/opus-tools/-/issues/2315Opusenc produces broken samples (wrong quantization) with 24-bit source2020-11-26T19:55:30ZstevenleleOpusenc produces broken samples (wrong quantization) with 24-bit source# Original Issue
I was encoding a specific sample of music (24 bits, 48 kHz) with `opusenc` in `opus-tools 0.2 (Opus 1.3)` and noticed a significant artifact in the beginning.
**More description:** You can hear the artifact within 00:01...# Original Issue
I was encoding a specific sample of music (24 bits, 48 kHz) with `opusenc` in `opus-tools 0.2 (Opus 1.3)` and noticed a significant artifact in the beginning.
**More description:** You can hear the artifact within 00:01. It's a broken "boom"-like sound.
Check the image below. The waveform graph has significant changes.
![comparison](/uploads/c4cc70aaf6ce4a578820caeb699f80dc/comparison.png)
This is how I encoded:
```
>opusenc sample.flac --bitrate 256 sample.opus
Encoding using libopus 1.3 (audio)
-----------------------------------------------------
Input: 48 kHz, 2 channels
Output: 2 channels (2 coupled)
20ms packets, 256 kbit/s VBR
Preskip: 312
Encoding complete
-----------------------------------------------------
Encoded: 1 minute and 31.1 seconds
Runtime: 1 second
(91.1x realtime)
Wrote: 2993392 bytes, 4555 packets, 94 pages
Bitrate: 261.351 kbit/s (without overhead)
Instant rates: 1.2 to 510.4 kbit/s
(3 to 1276 bytes per packet)
Overhead: 0.576% (container+metadata)
```
# Update
I tried using `FFmpeg` to convert the original file into 16 bits (original is 24 bits).
```
>ffmpeg -i sample.wav -f wav -c pcm_s16le sample_16bit.wav
```
Then I encoded again with the same settings.
```
>opusenc sample_16bit.wav --bitrate 256 sample_16bit.opus
Skipping chunk of type "LIST", length 26
Encoding using libopus 1.3 (audio)
-----------------------------------------------------
Input: 48 kHz, 2 channels
Output: 2 channels (2 coupled)
20ms packets, 256 kbit/s VBR
Preskip: 312
Encoding complete
-----------------------------------------------------
Encoded: 1 minute and 31.1 seconds
Runtime: 1 second
(91.1x realtime)
Wrote: 2990541 bytes, 4555 packets, 94 pages
Bitrate: 261.103 kbit/s (without overhead)
Instant rates: 1.2 to 510.4 kbit/s
(3 to 1276 bytes per packet)
Overhead: 0.576% (container+metadata)
```
The result turned out to be good.
Check the image below. The waveform graph has **no** significant changes now.
![comparison_2](/uploads/e1d820a879c854670ff562cd4b1e5d1d/comparison_2.png)
So there may be issue in quantization of 24-bit (or high bit depth?) samples.
# Sample Download
The updated sample files are [here](https://www.mediafire.com/file/jiat0cn2cjccu2y/sample_new.7z/file).
All source samples are converted to FLAC files for better compression.
The 16-bit sample is converted from the 24-bit one; the 24-bit one is the original, not padded.https://gitlab.xiph.org/xiph/opus/-/issues/2338cmake: wrong project version propagated to pkg-config file2020-11-21T18:29:34ZDonato Sciarracmake: wrong project version propagated to pkg-config fileWhen building the project as:
```
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=RELEASE
```
I get:
>>>
-- Opus library version: 0.8.0
-- Found Git: /usr/bin/git (found version "2.25.1")
-- Opus package version: 1.3.1
-- Opus pr...When building the project as:
```
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=RELEASE
```
I get:
>>>
-- Opus library version: 0.8.0
-- Found Git: /usr/bin/git (found version "2.25.1")
-- Opus package version: 1.3.1
-- Opus project version: 1.3.1
>>>
the "Opus library version" is propagated in the pkg-config file (at the time of writing 0.8.0). I discovered this while building tag 1.3.1 locally. Including opus in my cmake project as `pkg_check_modules(OPUS REQUIRED "opus")` returned:
> -- Found opus, version 0.8.0
I can live with it locally but I think it would good to fix it!https://gitlab.xiph.org/xiph/opus/-/issues/2332cmake - Add OPUS_TARGET_ARCH for crosscompiling from commandline for CMake build2020-11-21T06:59:41ZMarcus Asteborgcmake - Add OPUS_TARGET_ARCH for crosscompiling from commandline for CMake buildCurrently one need to use toolchain file for cross compiling, for easier crosscompiling in CI we can add a option to CMake so all cross compile options can be specified through commandline without the need for toolchain files.Currently one need to use toolchain file for cross compiling, for easier crosscompiling in CI we can add a option to CMake so all cross compile options can be specified through commandline without the need for toolchain files.https://gitlab.xiph.org/xiph/opus/-/issues/2335Remove WINCE define from source2020-11-21T06:59:12ZMarcus AsteborgRemove WINCE define from sourceWINCE is no longer relevant platform and defines can be removed from Opus sourceWINCE is no longer relevant platform and defines can be removed from Opus sourcehttps://gitlab.xiph.org/xiph/opus/-/issues/2336cmake - Rename options in CMake to have 1-1 mapping to autotools2020-11-21T06:58:42ZMarcus Asteborgcmake - Rename options in CMake to have 1-1 mapping to autotoolsdisable in autotools should be disable in cmake etc.disable in autotools should be disable in cmake etc.https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2299libshout with OpenSSL 1.1.02020-11-15T04:54:25Zmark burdettlibshout with OpenSSL 1.1.0tlschenkjr wrote @ https://github.com/xiph/Icecast-libshout/issues/7
> libshout contains calls to deprecated functions in openssl 1.1.0 and fails to build correctly. Any chance of that getting updated?
The error is: undefined reference...tlschenkjr wrote @ https://github.com/xiph/Icecast-libshout/issues/7
> libshout contains calls to deprecated functions in openssl 1.1.0 and fails to build correctly. Any chance of that getting updated?
The error is: undefined reference to `SSLeay_add_all_algorithms'https://gitlab.xiph.org/xiph/icecast-server/-/issues/2402Auth url webhooks not working2020-11-14T16:56:42ZJohn MidsonAuth url webhooks not workingHi guys,
Sorry if I'm missing something obvious, but I really can't make authentication url working.
I have Icecast configs:
```
<mount>
<mount-name>/aac_high</mount-name>
<authentication type="url">
<option...Hi guys,
Sorry if I'm missing something obvious, but I really can't make authentication url working.
I have Icecast configs:
```
<mount>
<mount-name>/aac_high</mount-name>
<authentication type="url">
<option name="listener_add" value="http://localhost:3000/api/v1/listeners/add"/>
<option name="listener_remove" value="http://localhost:3000/api/v1/listeners/remove"/>
<option name="auth_header" value="icecast-auth-user: 1"/>
</authentication>
</mount>
```
By calling `/aac_hight` I got 401 despite server is configured to return correct header:
```
$ curl http://localhost:8000/aac_high
<?xml version="1.0"?>
<report xmlns="http://icecast.org/specs/reportxml-0.0.1" version="0.0.1"><incident><state definition="25387198-0643-4577-9139-7c4f24f59d4a"><text>You need to authenticate</text></state></incident><extension application="http://icecast.org/specs/legacy-icestats"><icestats xmlns="http://icecast.org/specs/legacystats-0.0.1"><modules/></icestats></extension></report>
```
In Icecast's `error.log` I'm getting:
```
[2020-11-05 11:44:02] INFO auth/queue_auth_client auth on /aac_high has 1 pending
[2020-11-05 11:44:02] INFO auth_url/url_add_client client auth (http://localhost:3000/api/v1/listeners/add) failed with ""
[2020-11-05 11:44:02] WARN reportxml/reportxml_database_build_report No matching definition for "25387198-0643-4577-9139-7c4f24f59d4a"
```
So, looks like it is trying to reach `http://localhost:3000/api/v1/listeners/add` but in server logs I don't see any incoming request at all.
Callback on localhost:3000 working fine:
```
$ curl -v -X POST http://localhost:3000/api/v1/listeners/add
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 3000 (#0)
> POST /api/v1/listeners/add HTTP/1.1
> Host: localhost:3000
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< icecast-auth-user: 1
< Server: Dominion
< Date: Thu, 05 Nov 2020 12:19:24 GMT
< Connection: keep-alive
< Content-Length: 0
<
* Connection #0 to host localhost left intact
```
Icecast is built from master branch, additional info:
```
$ ./icecast -v
Icecast 2.4.99.2
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.3 LTS (Bionic Beaver)"
```
Will appreciate any hint what is going wrong. Thanks!https://gitlab.xiph.org/xiph/icecast-server/-/issues/2337RFE: Please add a possibility for a relay to transcode the stream2020-11-09T19:35:07Zpetr tomasekRFE: Please add a possibility for a relay to transcode the streamWith Icecast I'm missing the possibility to create transcoding relays in a simple manner. I'd suggest there could be a new configuration option which would specify a binary/script which the stream would go through.
Something like this:
...With Icecast I'm missing the possibility to create transcoding relays in a simple manner. I'd suggest there could be a new configuration option which would specify a binary/script which the stream would go through.
Something like this:
```xml
<relay>
<server>127.0.0.1</server>
<port>8001</port>
<mount>/example.ogg</mount>
<local-mount>/different.ogg</local-mount>
<on-demand>1</on-demand>
<retry-delay>30</retry-delay>
<relay-shoutcast-metadata>0</relay-shoutcast-metadata>
<transcode-bin>/usr/local/bin/transcodestreamXYZ</transcode-bin>
</relay>
```
Thanks!https://gitlab.xiph.org/xiph/ogg/-/issues/2290liboggplay mishandles live ogg streams in Firefox2020-11-06T04:06:07ZMilesliboggplay mishandles live ogg streams in Firefox(speculation)
See the following bug on Mozilla's tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=611519
Seems pretty likely the bug is actually in liboggplay. When an audio element points to a live stream and it is played in the...(speculation)
See the following bug on Mozilla's tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=611519
Seems pretty likely the bug is actually in liboggplay. When an audio element points to a live stream and it is played in the browser, it works fine for roughly 20 minutes before severe stutter sets in. Pressing play also tends to play permanently cached audio instead of the actual stream. Is liboggplay perhaps treating this case as an infinitely large file transfer instead of a live stream?Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/2041ogg-index sets incorrect fisbone message header offset in the skeleton stream2020-11-06T04:05:16ZNick Burchogg-index sets incorrect fisbone message header offset in the skeleton streamAccording to http://svn.annodex.net/standards/draft-pfeiffer-oggskeleton-current.txt , in the skeleton fisbone,
> Offset to message header fields: 4 Byte unsigned integer that
> contains the number of Bytes used in this packet before t...According to http://svn.annodex.net/standards/draft-pfeiffer-oggskeleton-current.txt , in the skeleton fisbone,
> Offset to message header fields: 4 Byte unsigned integer that
> contains the number of Bytes used in this packet before the
> message header fields. For the version of the skeleton
> bitstream described in this document this number is fixed to 44.
The skeleton stream generated by things like ffmpeg2theora and speexenc set the message header offset to be 44, which is the position less the fisbone\0 header
However, ogg-index creates fisbones where the message header offset is 0x2c=52, which is the offset including the fisbone\0 header, which (based on the docs) seems to be incorrect
Note that it is only the offset that is wrong, the message headers start in the expected place at 44 bytes after the fisbone header / 52 bytes after the start of the fisbone packet datahttps://gitlab.xiph.org/xiph/ogg/-/issues/2042ogg-index fails with an unhelpful error message if the file contains Speex or...2020-11-06T04:03:32ZNick Burchogg-index fails with an unhelpful error message if the file contains Speex or Opus streamsIf you try running ogg-index on a file which contains Opus or Speex streams (eg a Theora + Opus file), then you get a rather unfriendly error such as
`FAIL: Unhandled stream type, serialno=478384172 aborting indexing!`
Where the stream...If you try running ogg-index on a file which contains Opus or Speex streams (eg a Theora + Opus file), then you get a rather unfriendly error such as
`FAIL: Unhandled stream type, serialno=478384172 aborting indexing!`
Where the stream number is that of the Speex or Opus stream
Assuming it's not trivial to add support for those formats, it would be nice if ogg-index could instead give a more helpful message such as _Opus not supported (stream serialno=478384172) - aborting indexing! _