Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2019-01-09T11:59:13Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2322gzip http compression for server pages.2019-01-09T11:59:13ZRoger Hågensengzip http compression for server pages.With Icecast 2.4.x there is no gzip compression used for served pages.
While most served pages are not that large, gzip may be the difference between a page being served in one TCP packet vs multiple.
And then there are monstrosity lik...With Icecast 2.4.x there is no gzip compression used for served pages.
While most served pages are not that large, gzip may be the difference between a page being served in one TCP packet vs multiple.
And then there are monstrosity like this http://relay.sonixcast.com/ that would clearly benefit from gzip.
gzip could even be applied to xml stats pages as PHP and other serverside scripting languages also support gzip.
While technical it may be possible to apply gzip to the actual stream I would not advise that, the benefit would be minimal in most cases and the compatibility issues with older players could be high (they may support gzip pages but not gzip audiostreams for example).
gzip should probably be enabled by default so that the "optimal" settings are enabled "out of the box".
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/libao/-/issues/2317libao_pulse buffer calculation overflow2017-11-03T10:00:01ZGitlab Botlibao_pulse buffer calculation overflowIn tracking down the source of some strange behavior when setting buffer_time for the pulse plugin, I found a bug in the buffer length calculations that results in a multiplication overflow for some values. This overflow would set the bu...In tracking down the source of some strange behavior when setting buffer_time for the pulse plugin, I found a bug in the buffer length calculations that results in a multiplication overflow for some values. This overflow would set the buffer size to some absurdly-large value (~30 seconds in my case).
I've attached a patch that casts the multiplicands to a 64-bit int before the multiplication. This fixed the issue for me.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2311Parametrize TLS/SSL Protocol in Icecast config file2021-09-28T12:50:45ZGitlab BotParametrize TLS/SSL Protocol in Icecast config fileWe currently have the option of enabling SSL, defining ciphers and certificate files. Would you please add the option to define the protocol.
Example could be:
```
<SSL_Protocol>SSL_OP_NO_TLSv1|SSL_OP_NO_TLSv1_1|SSL_OP_NO_SSLv2|SSL_OP_...We currently have the option of enabling SSL, defining ciphers and certificate files. Would you please add the option to define the protocol.
Example could be:
```
<SSL_Protocol>SSL_OP_NO_TLSv1|SSL_OP_NO_TLSv1_1|SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3</SSL_Protocol>
```
The current ability to define ciphers is great but some ciphers are backwards compatible. From a security standpoint, it would be great to be able to control the protocols available.
Is there a workaround for me without needing to recompile as I've installed from Xiph repository.
Thank you so much for your time!Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/libao/-/issues/2307Inconsistent signedness of 8-bit samples2017-11-03T10:00:01ZDaniel Richard G.Inconsistent signedness of 8-bit samplesWhen playing 8-bit audio live, signed 8-bit samples work correctly.
When writing to a file with the "au" driver, signed samples also work correctly.
However, when writing to a "wav" file, signed samples yield incorrect output. The samp...When playing 8-bit audio live, signed 8-bit samples work correctly.
When writing to a file with the "au" driver, signed samples also work correctly.
However, when writing to a "wav" file, signed samples yield incorrect output. The samples must be converted to unsigned (by XOR'ing with 0x80) in order to produce a recognizable WAV file.
WAV files have the peculiarity of encoding 8-bit samples in unsigned form. I believe signed samples make more sense for API purposes, and Libao should handle the conversion itself when writing a WAV file.
(Currently, it is necessary to add special-casing to the application to perform this conversion when writing out an 8-bit WAV file.)Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/theora/-/issues/2304th_decode_headerin fails if malloc(0) returns NULL and header has no comments2017-08-20T01:57:17ZEric Lasotath_decode_headerin fails if malloc(0) returns NULL and header has no commentsmalloc(0) can return either a valid pointer or NULL depending on implementation. If it returns NULL, th_decode_headerin will return TH_EFAULT if it encounters a Theora header with no comments.
This happens because oc_comment_unpack per...malloc(0) can return either a valid pointer or NULL depending on implementation. If it returns NULL, th_decode_headerin will return TH_EFAULT if it encounters a Theora header with no comments.
This happens because oc_comment_unpack performs a NULL check on _tc->user_comments and _tc->comment_lengths even if _tc->comments is 0.https://gitlab.xiph.org/xiph/theora/-/issues/2303Cannot record videos into Theora2017-08-20T01:57:17ZAlberto Salvia NovellaCannot record videos into TheoraOriginally reported at:
https://bugs.launchpad.net/bugs/1655189
HOW TO REPRODUCE:
- Record a video using the Theora codec.
RESULT:
- In the recording the image is frozen or broken.
RELEVANT DETAILS:
- Doesn't matter which applicatio...Originally reported at:
https://bugs.launchpad.net/bugs/1655189
HOW TO REPRODUCE:
- Record a video using the Theora codec.
RESULT:
- In the recording the image is frozen or broken.
RELEVANT DETAILS:
- Doesn't matter which application you use to record or play the video.
- I'm attaching samples from various programs.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: libtheora0 1.1.1+dfsg.1-8
ProcVersionSignature: Ubuntu 4.4.0-57.78-generic 4.4.35
Uname: Linux 4.4.0-57-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.4
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Jan 10 01:17:54 2017
Dependencies:
gcc-6-base 6.0.1-0ubuntu1
libc6 2.23-0ubuntu5
libgcc1 1:6.0.1-0ubuntu1
libogg0 1.3.2-1
multiarch-support 2.23-0ubuntu5
InstallationDate: Installed on 2013-01-25 (1445 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
SourcePackage: libtheora
UpgradeStatus: Upgraded to xenial on 2016-08-05 (157 days ago)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2302Password extends into headers with BUTT shoutcast compatible source2020-02-14T13:26:12ZGary TunstallPassword extends into headers with BUTT shoutcast compatible sourceHi, I've found a bug in 2.4.3 (which if I understand correctly is the same as 2.4.2 for Linux).
Its a fairly minor one and is in part caused by the Source.
If you use BUTT (https://sourceforge.net/projects/butt/) to broadcast and setup a...Hi, I've found a bug in 2.4.3 (which if I understand correctly is the same as 2.4.2 for Linux).
Its a fairly minor one and is in part caused by the Source.
If you use BUTT (https://sourceforge.net/projects/butt/) to broadcast and setup an Icecast connection it works find. However if you set it up as a shoutcast connection and send to a shoutcast compatible port on icecast it fails.
Now the obvious question is why we'd use the "old" way of doing things. The answer is we are moving from shoutcast to icecast and a lot of our broadcasters still have the shoutcast settings and I'll like it to "just work" for them.
The problem is BUTT mixes its line endings, after the password there is just a /n but in the header lines it uses /r/n
In _handle_shoutcast_compatible in connection.c there is some code
```
/* Get rid of trailing \r\n or \n after password */
ptr = strstr (client->refbuf->data, "\r\r\n");
if (ptr)
headers = ptr+3;
else
{
ptr = strstr (client->refbuf->data, "\r\n");
if (ptr)
headers = ptr+2;
else
{
ptr = strstr (client->refbuf->data, "\n");
if (ptr)
headers = ptr+1;
}
}
```
Which unfortunately matches on the \r\n on the header, and misses the \n on the end of the password. So it uses the password a \n and the first line of the headers as the password, which fails and it rejects the connection.
For my purposes I've fix it by changing the code to:
```
/* Get rid of trailing \r\n or \n after password */
ptr = strstr (client->refbuf->data, "\n");
if (ptr)
{
headers = ptr+1;
while ( ( ptr > client->refbuf->data ) && ( ptr[-1]=='\r' ) )
{
ptr--;
}
}
```
So it finds the first \n and backtracks to remove any \r's
Obviously this is an edge case, in general people using BUTT will use icecast native connections, and most source client don't use mixed line endings. But I think my fixed version is probably more efficient on average anyway, so I think it should be safe to add.
I was going to try and submit a patch, but it looks like the code has moved on since the last version released, though even that didn't seem to use the latest changes at the time. So I'm not sure what is happening in that area. I'll leave this here and if its of any use then please include it. If you can shed more light on the evolution of the file and its worth it I can clone the latest version and test and if necessary make a patch for it.
Regards
GaryThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2300Write album art to encoded .ogg file2024-01-18T19:54:06ZtmpltWrite album art to encoded .ogg fileI use oggenc to create Ogg Vorbis files to save space on my mobile devices. While oggenc seems to write most metadata to the created .ogg file, the album art isn't copied. Could this be implemented?
CheersI use oggenc to create Ogg Vorbis files to save space on my mobile devices. While oggenc seems to write most metadata to the created .ogg file, the album art isn't copied. Could this be implemented?
CheersMichael SmithMichael Smithhttps://gitlab.xiph.org/xiph/opus-tools/-/issues/2297Add a "--bitrate-per-channel" or a "--quality" argument2018-05-13T08:51:36ZkuchikirukiaAdd a "--bitrate-per-channel" or a "--quality" argumentAs of now Opus doesn't have a setting equivalent to Vorbis, Nero AAC, or QAAC's VBR quality levels. This makes it difficult to batch encode multiple files with multiple channel configurations. With a quality level you can pick one sett...As of now Opus doesn't have a setting equivalent to Vorbis, Nero AAC, or QAAC's VBR quality levels. This makes it difficult to batch encode multiple files with multiple channel configurations. With a quality level you can pick one setting and the encoder will adjust the bitrate according to the channel layout: for example, QAAC @ q127 will target 320kbps for 2.0 channel and 768kbps for 5.1. This is a very handy feature.
If a --quality feature, may I suggest a naming scheme that has some relation to the bitrates output at 2.0? I mean, I'd have no idea what Vorbis' q=5.0 translates to without looking at a chart. QAAC, OTOH, seems to somewhat correspond to bitrate-per-channel in its q45-q91 range. This is pretty useful. I know to pick q91 if I want ~180k quality without needing to run off to a manual.
Mark HarrisMark Harrishttps://gitlab.xiph.org/xiph/tremor/-/issues/2296tremor: multiple invalid shift operations2017-09-02T15:25:02Zhannotremor: multiple invalid shift operationsThere are multiple invalid shift operations in the tremor codec.
To reproduce build tremor with clang and -fsanitize=undefined (undefined behavior sanitizer or ubsan). Then compile ivorbisfile_example.c that comes with it and pass the a...There are multiple invalid shift operations in the tremor codec.
To reproduce build tremor with clang and -fsanitize=undefined (undefined behavior sanitizer or ubsan). Then compile ivorbisfile_example.c that comes with it and pass the attached ogg file. Setting UBSAN_OPTIONS="print_stacktrace=1" gives a better output with stack traces.
Output from ubsan:
```
sharedbook.c:420:21: runtime error: left shift of 16 by 27 places cannot be represented in type 'int'
#0 0x53fdf3 in vorbis_book_init_decode /f/tremor/Tremor/sharedbook.c:420:21
#1 0x520f00 in _vds_init /f/tremor/Tremor/block.c:169:10
#2 0x520f00 in vorbis_synthesis_init /f/tremor/Tremor/block.c:229
#3 0x5173be in _make_decode_ready /f/tremor/Tremor/vorbisfile.c:595:8
#4 0x517925 in _fetch_and_process_packet /f/tremor/Tremor/vorbisfile.c:679:15
#5 0x51ad9d in ov_read /f/tremor/Tremor/vorbisfile.c:1934:15
#6 0x50aa11 in main (/f/tremor/Tremor/a.out+0x50aa11)
#7 0x7fcfccf8478f in __libc_start_main (/lib64/libc.so.6+0x2078f)
#8 0x419cc8 in _start (/f/tremor/Tremor/a.out+0x419cc8)
SUMMARY: AddressSanitizer: undefined-behavior sharedbook.c:420:21 in
misc.h:242:6: runtime error: left shift of negative value -134217728
#0 0x53d303 in VFLOAT_ADD /f/tremor/Tremor/./misc.h:242:6
#1 0x53a8a3 in _book_unquantize /f/tremor/Tremor/sharedbook.c:230:10
#2 0x53e493 in vorbis_book_init_decode /f/tremor/Tremor/sharedbook.c:383:18
#3 0x520f00 in _vds_init /f/tremor/Tremor/block.c:169:10
#4 0x520f00 in vorbis_synthesis_init /f/tremor/Tremor/block.c:229
#5 0x5173be in _make_decode_ready /f/tremor/Tremor/vorbisfile.c:595:8
#6 0x517925 in _fetch_and_process_packet /f/tremor/Tremor/vorbisfile.c:679:15
#7 0x51ad9d in ov_read /f/tremor/Tremor/vorbisfile.c:1934:15
#8 0x50aa11 in main (/f/tremor/Tremor/a.out+0x50aa11)
#9 0x7fcfccf8478f in __libc_start_main (/lib64/libc.so.6+0x2078f)
#10 0x419cc8 in _start (/f/tremor/Tremor/a.out+0x419cc8)
SUMMARY: AddressSanitizer: undefined-behavior misc.h:242:6 in
misc.h:77:68: runtime error: left shift of negative value -1
#0 0x546c70 in MULT31_SHIFT15 /f/tremor/Tremor/./misc.h:77:68
#1 0x546c70 in render_line /f/tremor/Tremor/floor1.c:323
#2 0x546c70 in floor1_inverse2 /f/tremor/Tremor/floor1.c:442
#3 0x558f86 in mapping0_inverse /f/tremor/Tremor/mapping0.c:285:5
#4 0x51799a in _fetch_and_process_packet /f/tremor/Tremor/vorbisfile.c:697:15
#5 0x51ad9d in ov_read /f/tremor/Tremor/vorbisfile.c:1934:15
#6 0x50aa11 in main (/f/tremor/Tremor/a.out+0x50aa11)
#7 0x7fcfccf8478f in __libc_start_main (/lib64/libc.so.6+0x2078f)
#8 0x419cc8 in _start (/f/tremor/Tremor/a.out+0x419cc8)
SUMMARY: AddressSanitizer: undefined-behavior misc.h:77:68 in
misc.h:71:21: runtime error: left shift of negative value -42347
#0 0x560d2f in MULT31 /f/tremor/Tremor/./misc.h:71:21
#1 0x560d2f in XPROD31 /f/tremor/Tremor/./misc.h:153
#2 0x55a3a5 in mdct_backward /f/tremor/Tremor/mdct.c:362:5
#3 0x55930d in mapping0_inverse /f/tremor/Tremor/mapping0.c:296:5
#4 0x51799a in _fetch_and_process_packet /f/tremor/Tremor/vorbisfile.c:697:15
#5 0x51ad9d in ov_read /f/tremor/Tremor/vorbisfile.c:1934:15
#6 0x50aa11 in main (/f/tremor/Tremor/a.out+0x50aa11)
#7 0x7fcfccf8478f in __libc_start_main (/lib64/libc.so.6+0x2078f)
#8 0x419cc8 in _start (/f/tremor/Tremor/a.out+0x419cc8)
SUMMARY: AddressSanitizer: undefined-behavior misc.h:71:21 in
misc.h:71:21: runtime error: left shift of negative value -4
#0 0x52a0c8 in MULT31 /f/tremor/Tremor/./misc.h:71:21
#1 0x52a0c8 in _vorbis_apply_window /f/tremor/Tremor/window.c:76
#2 0x55965f in mapping0_inverse /f/tremor/Tremor/mapping0.c:306:7
#3 0x51799a in _fetch_and_process_packet /f/tremor/Tremor/vorbisfile.c:697:15
#4 0x51ad9d in ov_read /f/tremor/Tremor/vorbisfile.c:1934:15
#5 0x50aa11 in main (/f/tremor/Tremor/a.out+0x50aa11)
#6 0x7fcfccf8478f in __libc_start_main (/lib64/libc.so.6+0x2078f)
#7 0x419cc8 in _start (/f/tremor/Tremor/a.out+0x419cc8)
```
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2295oggdec error - seems to be endianness problem2018-01-22T04:18:25ZMikeoggdec error - seems to be endianness problemI am trying to use ezstream to send a vorbis ogg music file to icecast. The error simplifies down to this - when I use the following two commands to manually decode and then encode an ogg file, the resulting test.ogg file plays correctl...I am trying to use ezstream to send a vorbis ogg music file to icecast. The error simplifies down to this - when I use the following two commands to manually decode and then encode an ogg file, the resulting test.ogg file plays correctly
oggdec -R -b 16 -e 0 -s 1 -o file.raw file.ogg
oggenc -r -B 16 -C 2 -R 44100 --raw-endianness 0 -q 5 -o test.ogg file.raw
But if I try to pipe the output of oggdec into the input of offenc as ezstream would do, the resulting file is only static. The defective pipe command is
oggdec -R -b 16 -e 0 -s 1 -o - file.ogg | oggenc -r -B 16 -C 2 \
-R 44100 --raw-endianness 0 -q 5 -o test.ogg -
However if I reverse the endianness in the pipe command of oggdec to -e 1 the resulting test.ogg plays properly. Somewhere in the handling of stdout the endianness is being reversed. This only happens when piping.
Version info:
linux 4.6.2
vorbis-tools-1.4.0
libvorbis-1.3.5
libogg-1.3.2
icecast-2.4.3
ezstream-0.6
Hardware is an intel i5 based system.
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/liboggplay/-/issues/1liboggplay mishandles live ogg streams in Firefox2023-06-08T14:38:55ZMilesliboggplay 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/icecast-libshout/-/issues/2288Outdated FSF address2018-07-16T09:13:39ZFrancisco de la PeñaOutdated FSF addressThis is a well known issue and a reporting this upstream is a requirement for some distribution packaging checks, so here it is.
The Free Software Foundation postal address mentioned in license texts changed.
The new address should be ...This is a well known issue and a reporting this upstream is a requirement for some distribution packaging checks, so here it is.
The Free Software Foundation postal address mentioned in license texts changed.
The new address should be the mentioned in http://www.gnu.org/licenses/old-licenses/lgpl-2.0.txt
The old address is found at least in the COPYING and source file headers.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/libao/-/issues/2286[PATCH] Revamped support for Microsoft Windows2017-11-03T10:00:01ZDaniel Richard G.[PATCH] Revamped support for Microsoft WindowsI've put together a patch to Libao, against Git master (currently `97c0dea6`), that fixes and simplifies the support for Windows.
First, I've added an NMAKE makefile that can be used with Microsoft Visual Studio. I have tested the build...I've put together a patch to Libao, against Git master (currently `97c0dea6`), that fixes and simplifies the support for Windows.
First, I've added an NMAKE makefile that can be used with Microsoft Visual Studio. I have tested the build with the following versions:
* Microsoft Visual C++ 6.0 (does not build due to missing APIs)
* Microsoft Visual Studio 2003 .NET
* Microsoft Visual Studio 2005
* Intel ICC 11.1 + MSVC9 Platform SDK
This is accompanied by a small batch file that handles the instantiation of `os_types.h` from `os_types.h.in`. Together, these allow building Libao using only Microsoft tools.
(I have further tested the linking of a small sound application with the built library, and confirmed that it works correctly.)
I've tweaked things so that on Windows, the system config for Libao is at
```
C:\Program Files\Common Files\Xiph.Org\libao.conf
```
and the user config is at
```
${LOCALAPPDATA}\Xiph.Org\libao.conf
```
This follows Windows conventions reasonably well without resorting to the Registry.
In `ao_private.h`, I've added two new sets of logging macros. One uses C99 syntax for variadic macros, supported by Visual Studio 2005 and later. The other is for older systems that do not support variadic macros at all. It's a hack, and has the shortcoming that messages are written to `stdout` instead of `stderr`, but it's better than nothing.
The remainder are small changes, which I'll describe below:
* `Makefile.am`: Added the two new Windows build files to `EXTRA_DIST`
* `include/ao/Makefile.am`: Don't include `os_types.h` (generated file) in the distribution tarball
* `include/ao/ao_private.h`: Use `strdup()` with an underscore prefix to keep the Microsoft compiler happy
* `src/ao_wmm.c`: Moved `-D_CRT_SECURE_NO_DEPRECATE` out to the makefile, because it also quashes warnings in the other source files
* `src/ao_wmm.c`: Use `#pragma comment(lib)` directives to bake in a reference to the two Windows libraries required by this code; this simplifies application linking later
* `src/ao_wmm.c`: Must `#include<ks.h>` or else you get this error:
```
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\KsMedia.h(16) : fatal error C1189: #error : KS.H must be included before KSMEDIA.H
```
(Also, you must still `#include<ksmedia.h>`, or else you don't get a usable definition of `KSDATAFORMAT_SUBTYPE_PCM`)
* `src/ao_wmm.c`: Add missing newlines to various logging macros
* `src/ao_wmm.c`: Check that `max` is greater than zero, because otherwise the system has no sound devices (saw this on a Windows VM)
* `src/ao_wmm.c`: Properly ignore unsupported options
* `src/audio_out.c`: `dirent.h` does not exist in Microsoft-land
* `src/audio_out.c`: Don't `#include"ao_private.h"`; this is #included from `ao.h`
* `src/audio_out.c`: Removed unused variable, flattened needless block
* `src/config.c`: Corrected AO header #including
* `src/config.c`: Removed unused variableMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/2282Sample rate: return effective value, option to disable auto-conversion2017-11-03T10:00:01ZDaniel Richard G.Sample rate: return effective value, option to disable auto-conversionI am writing a program based on LibAO that synthesizes sound. For this to work correctly, I need to know the exact sample rate that is in effect.
Unfortunately, this is at present not so straightforward in LibAO. Some drivers may not gi...I am writing a program based on LibAO that synthesizes sound. For this to work correctly, I need to know the exact sample rate that is in effect.
Unfortunately, this is at present not so straightforward in LibAO. Some drivers may not give you the exact rate you request, but something close. (Problem: You have no way of knowing what the real rate is.) Some drivers, like "alsa", will actually give you any arbitrary sample rate you choose (let's do 512 kHz!) but actually resample in software to whatever the hardware wants. (Problem: This eats up CPU, and messes up my synthesis.)
The attached patch (against git master) addresses these issues:
1. As far as I can tell, only the "alsa", "macosx" and "oss" drivers can give you a sample rate different than what you requested. In these, I added code to update the ao_sample_format struct that was passed in to reflect the actual rate. This way, the calling program can subsequently examine the struct to see what it got.
(The same thing could potentially be done with other parameters in there, like the channels. I think this would be a good pattern to follow generally, as the struct is otherwise useless after the ao_open_*() call.)
2. Pass in SND_PCM_NO_AUTO_RESAMPLE to the snd_pcm_open() call in ao_alsa.c, to disable the "dmix" resampling layer. If you request a rate of 512000, you should see a "sample rate not supported" warning and get an actual rate like 48000; you should not get a software simulation of a 512 kHz ultra-hi-def sound card.
(FYI: the snd_pcm_hw_params_set_rate_resample() function may be another way of going about this. I used the aforementioned open-mode flag only because I saw its use in a patch to VLC's ALSA driver.)Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/oggdsf/-/issues/2278OGG files won't play on Windows 8.12018-04-29T07:18:12Zkaoruchan42OGG files won't play on Windows 8.1I can't get .ogg files to play in any media player on my Windows 8.1 computer. I've uninstalled and reinstalled the codec files several times, but I still get this error from Windows Media Player:
"Windows Media Player cannot play the ...I can't get .ogg files to play in any media player on my Windows 8.1 computer. I've uninstalled and reinstalled the codec files several times, but I still get this error from Windows Media Player:
"Windows Media Player cannot play the file. The Player might not support the file type or might not support the codec that was used to compress the file."
I then tried installing the VLC media player, but I get this error:
"VLC can't recognize the input's format:
The format of 'file:///C:/Users/User/Desktop/File_Durgotsav_Pronun.ogg' cannot be detected. Have a look at the log for details."
Any help would be greatly appreciated.Cristian AdamCristian Adamhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2276oggenc in vorbis-tools versions 1.4.0, 1.2.0, 1.1.1 suffer from DoS(infinite ...2018-01-22T04:18:25ZWang Pengoggenc in vorbis-tools versions 1.4.0, 1.2.0, 1.1.1 suffer from DoS(infinite loop) with crafted input file1. the phenomenon
# ./oggenc/oggenc exploit_1_0
output got:
Skipping chunk of type "", length -8
2. the analysis (Version 1.4.0 as an example)
audio.c:126 if(fread(buf,1,*8*,in) < 8 ) /* Suck down a chunk specifier */
(gdb)x/8xb buf
...1. the phenomenon
# ./oggenc/oggenc exploit_1_0
output got:
Skipping chunk of type "", length -8
2. the analysis (Version 1.4.0 as an example)
audio.c:126 if(fread(buf,1,*8*,in) < 8 ) /* Suck down a chunk specifier */
(gdb)x/8xb buf
0xbffff254: 0x00 0x00 0x00 0x00 0xf8 0xff 0xff 0xff
here! 0xfffffff8 == *-8*
audio.c:134 *len = READ_U32_LE(buf+4);
(gdb)p/x *len
$7 = 0xfffffff8
audio.c:135 if(!seek_forward(in, *len))
audio.c:101 if( fseek(in, length, SEEK_CUR))
(gdb)p/x length
$15 = 0xfffffff8
In conclusion, fread() forwards the file position by 8 bytes and then fseek() backwards it by 8 bytes, meaning resets it;More worse,this happens within a while(1) loop,at audio.c:124 ,which results in the infinite loop.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2270If relay with on-demand's source goes down, on_demand is no longer reported i...2020-10-11T11:40:22ZdonicsIf relay with on-demand's source goes down, on_demand is no longer reported in status-json.xsl when source returns.If you set up a relay with on-demand=1 in the relay settings, status-json.xsl will report the setting as on_demand=1. This is great, and helps with calculating total viewers on a source.
One thing I have found, though, is that if the so...If you set up a relay with on-demand=1 in the relay settings, status-json.xsl will report the setting as on_demand=1. This is great, and helps with calculating total viewers on a source.
One thing I have found, though, is that if the source goes down, the relay will stop reporting on_demand status-json.xsl. This continues even when the source comes back up. The only way to get on_demand reporting back is to restart the service.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2263Add mime.types paths for other distros2020-10-11T14:45:20ZMarvin ScholzAdd mime.types paths for other distrosWe should add some more mime.types paths, seems the current one we have does not work on FreeBSD
and OS X uses a different one.
See [this](https://groups.google.com/forum/#!topic/golang-codereviews/fIw6mRzai4U) for some more paths that ...We should add some more mime.types paths, seems the current one we have does not work on FreeBSD
and OS X uses a different one.
See [this](https://groups.google.com/forum/#!topic/golang-codereviews/fIw6mRzai4U) for some more paths that seems to be usual.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://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 Montgomery