similar to: [Patch] New function of libvorbis

Hi, not sure who to send this to, since it seems to be duplicated in both speex and liboggz, so I'm sending to the whole list. This fixes an off by one bug in the user of snprintf, and returns negative if writing the header returns negative (otherwise we'd just get a short write, losing the error). This patch isn't tested though, but I compiled it :) Also, I've not fixed this

Hi, not sure who to send this to, since it seems to be duplicated in both speex and liboggz, so I'm sending to the whole list. This fixes an off by one bug in the user of snprintf, and returns negative if writing the header returns negative (otherwise we'd just get a short write, losing the error). This patch isn't tested though, but I compiled it :) Also, I've not fixed this

"Ogg Vorbis uses the Ogg bistream format, and the correct extension is .ogg" -- http://www.xiph.org/ogg/vorbis/faq.html I'm guessing it should read 'bitstream'. <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org'

Hello list, As some of you may have noted, the release of libvorbis 1.2.1 was put on hold, I reckon due to the possible unavailability of the main developer to review certain patches to solve issues found recently in libvorbis. So, why not ask help from the community to speed up this process? This is what this thread will be about. Let's go into detail regarding the two issues I mentioned

Hi, I have a question about the format of Theora bitstream header. It seems to me that there are differences between the specification[1] (version 2004 Oct 1) and its reference implementation in libtheora 1.0alpha3 released at 2004 Jun 1. I mean that... please refer to Section 6.2 'Identification Header Decode' in that specification[1] and the function

Hi all. In lib\encoder_toplevel.c , row 1123-1128: #ifndef LIBOGG2 /* So we're expecting the application with free this? */ op->packet=malloc(oggpack_bytes(opb)); memcpy(op->packet, oggpack_get_buffer(opb), oggpack_bytes(opb)); oggpack_writeclear(opb); #else In my small testing application my debugger says there are 50 bytes of memory lost and it refers to

Hi all. In lib\encoder_toplevel.c , row 1123-1128: #ifndef LIBOGG2 /* So we're expecting the application with free this? */ op->packet=malloc(oggpack_bytes(opb)); memcpy(op->packet, oggpack_get_buffer(opb), oggpack_bytes(opb)); oggpack_writeclear(opb); #else In my small testing application my debugger says there are 50 bytes of memory lost and it refers to

The theora_unpack_comment casts a pointer-to-int to pointer-to-long. This is incorrect on AMD64, where ints and longs are of different size. On my system (Debian unstable, gcc 4.1) this causes players to crash when they reach the end of a movie. The patch below fixes this bug. --- libtheora-0.0.0.alpha7/lib/toplevel.c 2006-06-13 00:57:36.000000000 +0200 +++ libtheora-pdw/lib/toplevel.c

Hi, I am making good progress on understanding, documenting, and re-implementing VP3. I have found some more deadwood in the decoder code and I just wanted to verify that it really has no place: * Version 3.3 tables: There are 2 sets of VLCs: One for v3.1 and one for v3.3. The v3.1 set is always selected. Are the v3.3 tables in production, or will they ever be? * DC Search Points: VP3

Hello! First of all a question: When you make the encoder tables (ie: mode_e.h) do you use the mapping0_forward function? Because you made the encoder tables, and after this you did a minor correction in the final beta4 ... (this correction was: additional[0]=fabs(additional[0]*scale); in the mapping0_forward function) (I see this was a bug, and the modification was correct, but this correction

The comments strings in vorbis are to be 8-bit clean. info.c _v_writestring is not 8-bit clean. This leads to a malformed comment header packet if the comment has an embedded Null: 0:0 hdr2 03 76 6F 72 62 69 73 20 00 00 00 58 69 70 68 6F .vorbis ...Xipho 16:10 70 68 6F 72 75 73 20 6C 69 62 56 6F 72 62 69 73 phorus l ibVorbis 32:20 20 49 20 32 30 30 31 30 38 31 33 01 00 00

This is a maintenance release of Puppet Dashboard. This release resolves issues #7405, #9101, #8878, and #8803. More details below. This release is available for download at: http://downloads.puppetlabs.com/dashboard/ We have included Debian and RPM packages as well as a tarball. See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

On 31/01/2008, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > Hi, > > not sure who to send this to, since it seems to be duplicated in both > speex and liboggz, > so I'm sending to the whole list. thanks, this is an appropriate place for that patch. That skeleton.c comes from a Summer of Code project which put skeleton support into many projects;

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm pleased to announce the release of libogg 1.3.2. The 'libogg' library is Xiph.Org's reference implementation of the Ogg media container. This release fixes an issue which could cause oggpack_write to fail. There are no other substantial changes. Upgrading is recommended for all users. *

Lancer 20060807 (based on aoTuV 4.51) http://homepage3.nifty.com/blacksword/ 2006/08/07 Lancer 20060807 Changes: * fix SSE optimization code in mdct_forward, mdct_backward. * reintroduce vorbis_oggpack_write for only static version. * fix problem in local_book_besterror_dim1x4. 2006/08/06 Lancer 20060807(test version for memory problem) Changes: * Since heap memory error occurs, remove

Hi we run a util at work called 'bounds checker' and it came up with this little beauty: void oggpack_readinit(oggpack_buffer *b,unsigned char *buf,int bytes){ memset(b,0,sizeof(oggpack_buffer)); b->buffer=b->ptr=buf; b->storage=bytes; } Stack memory overrun: Copying 20 bytes to opb; Starting offset 0, destination size 4 bytes. This is in RC1 code base. Any ideas?

On 01/02/2008, Conrad Parker <conrad@metadecks.org> wrote: > On 31/01/2008, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > > This fixes an off by one bug in the user of snprintf, and returns > > negative if writing the > > header returns negative (otherwise we'd just get a short write, losing > > the error). > > This patch

jg <webaccounts173 at jgoettgens.de> schrieb: > It doesn't really depend on your sip.conf and Asterisk. Your gateway/router > will be the major problem. My summer project will be to look at session Are you sure? Right now I'm using an italian SIP-Provider (Messagenet), configured in my sip.conf and I can receive calls without any problem... So, I don't think, I have to

Dear All, I am trying to cross compile the dependencies of ices for arm linux. I have been able to compile libxml2 (2.6.32) and libogg (1.1.3) successfully but I am getting stuck at compiling libvorbis (1.2.0). Making install in examples make[1]: Entering directory `/home/sr/armlinux/stream/libvorbis-1.2.0/examples' /bin/bash ../libtool --tag=CC --mode=link /usr/local/arm/bin/arm-linux-gcc

On 7/16/15, Martin Leese <martin.leese at stanfordalumni.org> wrote: > Martijn van Beurden wrote: >> I would propose: 0000-0111 : (number of independent channels)-1. >> The channel order is defined through the >> WAVEFORMATEXTENSIBLE_CHANNEL_MASK vorbis comment, if defined. If >> no WAVEFORMATEXTENSIBLE_CHANNEL_MASK is present, the channel >> order follows