search for: skuldwyrm

So what happened with Icecast v2.5? There was a beta once over a year ago then nothing. -- Roger Hågensen, Freelancer, http://skuldwyrm.no/

Hi. Is it possible (legally) to stream MP3s on Icecast that have been encoded with LAME encoder (http://lame.sourceforge.net/license.txt)? So if a composer writes a track, then saves in MP3 with LAME, and wants to distribute with Icecast server, is it legal? Must he get license for MP3 (http://mp3licensing.com/royalty/emd.html) and pay any royalties for MP3 DISTRIBUTING or STREAMING as it stated

On 04/20/2015 05:47 AM, Ralph Giles wrote: > On 19/04/15 08:15 PM, "Thomas B. R?cker" wrote: > >> If anyone happens to know about proven secure settings, just like the >> Mozilla labs settings for server side, please let us know. > You mean like https://wiki.mozilla.org/Security/Server_Side_TLS ? Yes, that's what we used for the Icecast server default cipher

Hi, as some of you might know Philipp has been working hard on adding TLS support to libshout, and a few other things. Originally we were planning to publish a beta or snapshot today, but we didn't manage to agree on a openssl client side cipher list yet. If anyone happens to know about proven secure settings, just like the Mozilla labs settings for server side, please let us know. We want

Hey Roger and everyone else commenting – I appreciate all the advice and questions. I now have more work than before 😊! Greetings from sunny South Africa! Sent from Mail for Windows 10 From: Roger Hågensen Sent: Thursday, May 2, 2019 12:12 PM To: icecast-dev at xiph.org Subject: Re: [Icecast-dev] Webm files written without duration in header On 2019-05-01 11:58, Sytze Visser wrote:> I am

...is it possible to use TLSv1.2 only? (in other words excluding TLSv1.1) By the looks of it TLSv1.2 uses SHA256 for all ciphers (basically excluding the use of MD5/SHA1). So if TLSv1.2 works fine with Icecast then those old hash methods can be avoided fully. -- Roger H?gensen, Freelancer, http://skuldwyrm.no/

I am a software developer myself. We develop a Radio Automation System/Broadcasting. Hence we are using the reference encoders. For OGG there is LUCKILY still the admin interface working to update meta data mid-stream. That is why my post is related to the other ogg based formats: FLAC and OPUS! Tractor Pro is btw not supporting FLAC or OPUS and alao uses the admin update interface! As such

On 2019-08-14 08:35, Bernd wrote: > Most users do use ICEcast to stream a continuous stream, e.g. they stream a live DJ or radio program. > I.e. they setup a single encoder on a single audio stream. > Still this logical stream contains different tracks being played over its time, and as such those users would like to update ICEcast to inform their listeners about the changing tracks

On 2019-08-16 08:10, Bernd Niedergesäß wrote: > I am a software developer myself. We develop a Radio Automation System/Broadcasting. Hence we are using the reference encoders. > > For OGG there is LUCKILY still the admin interface working to update meta data mid-stream. > That is why my post is related to the other ogg based formats: FLAC and OPUS! > > Tractor Pro is btw not

On 2019-05-01 11:58, Sytze Visser wrote:> I am streaming live with webm with ffmpeg to icecast 2.4.2. After the > stream ends, I am unable to determine the duration of the file using > ffprobe or mediainfo. Not sure but it seems that this has to do with > headers? > > Should icecast be writing the duration into the header or should this > somehow be passed from ffmpeg?

While http://127.0.0.1:8000/status-json.xsl?mount=/live is fine for info on the server itself and the current track played it's missing a played history. I'd like to suggest adding history to status-json.xsl or to reduce the size of the json to the bare minimum that a Web base mediaplayer might need Add a new one at http://127.0.0.1:8000/playing-json.xsl?mount=/live Which will only

On 2017-03-03 13:37, Marvin Scholz wrote: > >> I'd like to suggest adding history to status-json.xsl or to reduce >> the size of the json to the bare minimum that a Web base mediaplayer >> might need >> Add a new one at http://127.0.0.1:8000/playing-json.xsl?mount=/live >> Which will only hold the current info: > > Right now I personally don't think