similar to: [PATCH] Prevent Icecast from barfing on Vorbis+Skeleton

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

On 2/2/08, Conrad Parker <conrad@metadecks.org> wrote: > As far as I understand, that file is simply duplicated in each source > tree. It would be great if you could update it in each. I don't think it is that easy. I have made a mere diff and see so many differences I'm not sure we can just blindly replace every skeleton.c with the one used in liboggz. Diff attached. -Ivo

I noticed this first in vorbis-tools and later in ffmpeg2theora. The Skeleton bitstream contains a header called Content-Type. It lists the media types of all the data in Ogg. In vorbis-tools and ffmpeg2theora the output is normally Vorbis and Theora. The Skeleton implementation there reports those media types as video/x-theora and audio/x-vorbis. I would like to suggest that it would be

I'm patching oggenc with this fix. If Conrad reports success in his test, I'll go ahead and patch all other implementations I can find. -Ivo

I'm patching oggenc with this fix. If Conrad reports success in his test, I'll go ahead and patch all other implementations I can find. -Ivo

illiminable wrote: > > ----- Original Message ----- From: "Ian Malone" <ibmalone@gmail.com> > To: <ogg-dev@xiph.org> > Sent: Friday, March 10, 2006 8:42 AM > Subject: Re: [ogg-dev] oggfile, skeleton and vorbis tools > > >> Re-reading Monty's email: when you talk about vorbis-only vorbisfile and >> the concurrent vorbis stream case do

----- Original Message ----- From: "Ian Malone" <ibmalone@gmail.com> To: "ogg-dev" <ogg-dev@xiph.org> Sent: Friday, March 10, 2006 5:24 PM Subject: Re: [ogg-dev] oggfile, skeleton and vorbis tools >> This is something we might want to extend skeleton to support, i know >> we've talked about this kind of thing before. So that skeleton can

Jean-Marc, you might like to simply copy the skeleton.c from liboggz, as described below. cheers, Conrad. ---------- Forwarded message ---------- From: Conrad Parker <conrad@metadecks.org> Date: 2 Feb 2008 16:41 Subject: Re: [ogg-dev] [PATCH] skeleton.c To: Ivo Emanuel Gon?alves <justivo@gmail.com> Cc: "ogg.k.ogg.k@googlemail.com" <ogg.k.ogg.k@googlemail.com>,

On 06/02/2008, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > I've had a second look, and I believe there really was a bug there, > though my patch may not be optimal. > > As an example of an off by one bug: > > On the first run through the code, message_header_fields will be NULL, > so _ogg_calloc will be called. Assume header_key and header_value

On 02/02/2008, Ivo Emanuel Gon?alves <justivo@gmail.com> wrote: > I'm patching oggenc with this fix. If Conrad reports success in his > test, I'll go ahead and patch all other implementations I can find. I've merged this patch and fixed the other problems that were reported in the liboggz source tree: http://svn.annodex.net/liboggz/trunk/src/tools/skeleton.c It includes

----- Original Message ----- From: "Ian Malone" <ibmalone@gmail.com> To: <ogg-dev@xiph.org> Sent: Friday, March 10, 2006 8:42 AM Subject: Re: [ogg-dev] oggfile, skeleton and vorbis tools > Re-reading Monty's email: when you talk about vorbis-only vorbisfile and > the concurrent vorbis stream case do you mean vorbisfile will need to be > able to choose?

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;

Dear vorbis-dev lurkers, I bring you the first beta release of vorbis-tools 1.3.0. It has quite a few new features and the final version will have even more, so I am sure it is to everyone's benefit that it gets as much tested as possible so we can do a quick release. Here's the changelog so far: * Fixed an error in configure.ac; --with-speex/flac work again (#1319) * Corrected

On 1/23/08, jaromil <jaromil@dyne.org> wrote: > nope. we have a freej specific mailinglist, see http://lists.dyne.org Ah, so sorry. > freej is statically including theora-mmx or offering to be dynamically > compiled to system-wide theora libraries (so the issue is then > delivered to the distribution) Most distros should be already using the latest beta, so that should

(w. quotes from the xiphmeet: <http://westfish.xiph.org/~giles/200603_meeting.txt>, I've tried to strip it down to relevant stuff) <xiphmont> "Is there any interest in extending vcedit/libvorbisfile to do basic handling of Vorbis streams from concurrently multiplexed Ogg?" < xiphmont> Yes, but that work was *also* tied to OggFile from way back when, and one

On 10/21/07, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > But I agree that we need to get skeleton support into mainstream > encoders, not just the decoders. That's what I meant, especially now that Skeleton is a (SHOULD) requirement for video/ogg and audio/ogg. Lots of encoders will need to change. ffmpeg2theora, flac (the application), VLC... And CMML... I believe I

In one of the last monthly meetings it was decided that OggPCM is ready and all it needs is an implementation (for instance, in ogg123). The problem is that nobody seems available to do it. If either Martin or Sampo would like to work on it, I believe nobody will oppose. CMML and Skeleton implementations are far more urgent right now, though. I have changed the main page in the XiphWiki to

I agree. Is it both in the code and in the documentation? I shall look at the documentation over easter. Cheers, Silvia. On Wed, Mar 12, 2008 at 1:51 PM, Ivo Emanuel Gon?alves <justivo@gmail.com> wrote: > I noticed this first in vorbis-tools and later in ffmpeg2theora. The > Skeleton bitstream contains a header called Content-Type. It lists > the media types of all the data in

On 3/20/08, Conrad Parker <conrad at metadecks.org> wrote: > I agree that tools should now start writing media types without the x- . Cool. j^ reported that some of the tools in the Annodex SVN like mod_annodex, anxrip, oggz-merge, oggz-rip, etc will need to be modified. I do not have SVN access to edit these, so can one of you guys do it? With j's consent, I'll edit