similar to: [libshout] Add mime/content-type parameter

Le Monday 22 September 2008 18:48:34 Ivo Emanuel Gon?alves, vous avez ?crit?: > On 9/22/08, Romain Beauxis <toots at rastageeks.org> wrote: > > I don't get where the patch should be changed ? The default mime value > > for ogg streams ? > > Yep. ?Any of the three media types should be allowed. ?There is simply > no "default mime" anymore. > >

On 9/24/08, Romain Beauxis <toots at rastageeks.org> wrote: > First patch is 100% backward compatible, and only documents the new > audio/ogg and video/ogg mime types. "Documents" doesn't sound good. A quick look at the patch seems to imply that libshout doesn't act on those two. > Second patch is not backward compatible and sets "audio/ogg" if you

On 9/25/08, Romain Beauxis <toots at rastageeks.org> wrote: > No, the API is 100% backward compatible. Only difference is that programs > that use the (deprecated) SHOUT_FORMAT_VORBIS will then send the > "audio/ogg" mime type instead of "application/ogg". I don't believe this will > cause any trouble. I'm sold. If nobody sees a reason to oppose

Hi ! Le Monday 22 September 2008 18:32:57 Ivo Emanuel Gon?alves, vous avez ?crit?: > It seems like a fine patch, but you need to revise it because > video/ogg and audio/ogg are registered media types for Ogg streams > too. ?This, of course, is something recent, so don't blame yourself if > you haven't heard. Thanks for the review ! I don't get where the patch should be

Le Monday 22 September 2008 19:04:48 Romain Beauxis, vous avez ?crit?: > Humm.. > So default mime would remain "application/ogg", but "audio/ogg" > and "video/ogg" should be documented, right ? > > It is also be possible to add new formats, which would be: > ?* SHOUT_FORMAT_OGG_AUDIO > ?* SHOUT_FORMAT_OGG_VIDEO > with the corresponding default

I propose the following changes to the libshout API to support nonblocking I/O: New functions: int shout_set_nonblocking(shout_t *self, unsigned int nonblocking): Instructs libshout to use nonblocking I/O. Must be called before shout_open (no switching back and forth midstream at the moment). unsigned int shout_get_nonblocking(shout_t *self): self-explanatory. Changed functions:

>This is in subversion now. I'll try to get a new release out this >weekend. Thanks! Thanks! But I noticed that giving up the global interpretor lock in a few functions allows other threads to do something stupid (like deleting the shout object during a write). So for everything to be absolutely thread safe a python shout object should contain a mutex and there should be appropriate

Karl Heyes wrote: >> In file included from sock.c:49: >> sock.h:32: os.h: No such file or directory >> make[2]: *** [sock.lo] Error 1 >> make[2]: Leaving directory `/opt/ices2/libshout/src/net' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory `/opt/ices2/libshout/src' >> make: *** [all-recursive] Error 1 > > > yes

The open source fdk-aac encoder, available there: https://github.com/mstorsjo/fdk-aac offers pretty good quality. As for libshout, I do not think that it is currently posible to send AAC data using it. First, libshout doesn't have support to buffer and control timing of data sent. And even is you use the un-timed API (shout_send_raw), the library cannot set the proper mime type, due to a

The init functions are not longer required in OpenSSL 1.1 so I dropped them. TLSv1_client_method() should not be used because it enables only the TLSv1.0 protocol. Better is to use SSLv23_client_method() which enable all the protocols including TLSv1.2. With this functions SSLv2 and SSLv3 is theoretically possible but as of today those protocols are usually build-time disabled. To avoid all this

Hi, On 25 June 2013 22:56, Romain Beauxis <toots at rastageeks.org> wrote: > Hi, > > 2013/6/25 "Thomas B. R?cker" <thomas at ruecker.fi>: >> On 06/24/2013 06:27 PM, Thomas R?cker wrote: >>> Just going to drop my 0,02? here too. >>> >>> On 24 June 2013 16:47, Daniel James <daniel.james at sourcefabric.org> wrote:

>Why would you keep a non-thread safe API ? I do not want to touch libshout. I am only concerned with the python bindings. Probably Brendan can answer this better but I think libshout is not thread safe for simultaneous accesses to a shout_t object. This is not a problem as the posix locking primitives are trivial to use. For python apis should in principle be absolutely thread safe.

Hi Guys, 2012/7/20 juantello <juantello1234 at gmail.com>: > > Hello. > > Icecast client for android > http://droidtools.sourceforge.net/content/icecast-client-android > http://droidtools.sourceforge.net/content/libogglibvorbis-and-libshout-libraries-android I just finished compiling an android version of our reshaped shine encoder [1] there:

Le jeudi 13 mai 2010 05:46:12, jaromil a ?crit : > re all, Hi, > this patch has not been integrated in Debian yet, hence the Icecast2 > package still segfaults after filling up all the memory with its leak. > > as this is a critical bug, while it seems that the current Debian > mantainer for the icecast2 package has abandoned its duty, i'm kindly > asking

Hi just saw this today :a real icecast client on android ! Seems to have been published on november 2012 : https://play.google.com/store/apps/details?id=sa.broadcastmyself <-----------------------------------------------------------------------------------------------------------> web perso : http://memeteau.org <xmpp%3Afreechelmi at jabber.fr> 2012/8/24 Romain Beauxis

Mihai, Here's the full backtrace. (gdb) bt full #0 0x40292093 in strlen () from /lib/i686/libc.so.6 No symbol table info available. #1 0x40291dc5 in strdup () from /lib/i686/libc.so.6 No symbol table info available. #2 0x400aed79 in _shout_util_dict_set (dict=0x0, key=0x804b746 "song", val=0x0) at util.c:236 prev = (util_dict *) 0x80555b8 #3 0x400ad61b in

html5/js source client? (Xabier Oneca -- xOneca) 2014-05-04 21:00 GMT+02:00 <icecast-request at xiph.org>: > Send Icecast mailing list submissions to > icecast at xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.xiph.org/mailman/listinfo/icecast > or, via email, send a message with subject or body 'help' to

Hello , We are using Icecast for few years in a small french radio station with great success ! ( hitting 60 simultaneous listeners sometimes :-) ) http://www.radiogalere.org:8080/ Now we plan to stream the webcam capture of the studio, we 've done a test with Ogv/theora @128kb video with great sucess although none of the HTML5 browser wher able to keep on playing the stream after few

Hi all, 2012/2/29 Tom Swirly <tom at swirly.com>: > On Wed, Feb 29, 2012 at 11:29 AM, Raymond Lutz <raylutz at cognisys.com> wrote: >> >> This is absolutely not "off-topic" and if this list will not support this >> VERY IMPORTANT discussion, then I will be happy to host the discussion on a >> different list for those who are interested. I have been

Hi all, 2012/8/21 Romain Beauxis <toots at rastageeks.org>: > Hi Guys, > > 2012/7/20 juantello <juantello1234 at gmail.com>: >> >> Hello. >> >> Icecast client for android >> http://droidtools.sourceforge.net/content/icecast-client-android >> http://droidtools.sourceforge.net/content/libogglibvorbis-and-libshout-libraries-android > > I