similar to: [PATCH] oggz_tools.c

A widely used platform doesn't bother to have C99 integer types, so this allows building with it. Reported by sirlemonhead on IRC. Index: src/tools/oggz_tools.c =================================================================== --- src/tools/oggz_tools.c (revision 3827) +++ src/tools/oggz_tools.c (working copy) @@ -450,7 +450,7 @@ dg->pt = (iframe + pframe) >> 9;

Hi, I'm wondering if the Dirac granulepos parsing in liboggz and display in the oggz tools is currently correct, as I'd like to do a release of these soon. A couple of days ago David Schleef mentioned there were some problems. David, is that currently true (ie. since David Flynn's recent updates to support Dirac), and if so could you please explain what the problems are, or point me

2008/11/14 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote: >> I'm wondering if the Dirac granulepos parsing in liboggz and display >> in the oggz tools is currently correct, as I'd like to do a release of >> these soon. > > I believe it is -- although if correct support in the rest of the >

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

When I try to 'make' oggz (0.9.9), I get the following compile error make[4]: Leaving directory `/c/liboggz/src/tools/oggz-chop' make[4]: Entering directory `/c/liboggz/src/tools' /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wextra -g -std=gnu99 -Wdeclaration-after-statement -Wno-unused -o oggz-info.exe oggz-info.o skeleton.o oggz_tools.o dirac.o

On 2008-11-14, Conrad Parker <conrad at metadecks.org> wrote: > Should oggz-comment be modified to disallow modification of Dirac > streams, ie. does Ogg Dirac never contain VorbisComment metadata? Correct; there is no metadata handling capability in the current mapping spec. > It seems oggz chop, merge and sort will need some attention to deal > with the Dirac granulepos and

On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote: > I'm wondering if the Dirac granulepos parsing in liboggz and display > in the oggz tools is currently correct, as I'd like to do a release of > these soon. I believe it is -- although if correct support in the rest of the liboggz tools is required, a little more work may need to happen. > Here's some

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

2008/11/15 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-14, Conrad Parker <conrad at metadecks.org> wrote: >> It seems oggz chop, merge and sort will need some attention to deal >> with the Dirac granulepos and dependency ordering, so let's leave them >> for the next release. > > ok. -- may be worth having them 'warn' if they are operating

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

>> hmm, perhaps we should add some configure arguments like >> --with-firefox-cflags= and --with-firefox-libs= > > I've made it a single one, --with-gecko-sdk= and also default > include path and xpidl path to that if specified. Hi, I noticed this hasn't been applied, so I'm sending it again as it's quite simple and, I think, unobtrusive. It allows building

Package: liboggz Version: 0.9.0 Status: Severity: normal [Keep CC if you reply, I'm nt in this list] After porting the package to Cygwin, some binaries do not have accompnying manual pages. ... .inst/usr/share/man/man1/oggzdump.1.gz .inst/usr/share/man/man1/oggzdiff.1.gz .inst/usr/share/man/man1/oggzmerge.1.gz .inst/usr/share/man/man1/oggzrip.1.gz .inst/usr/include .inst/usr/include/oggz

Hi, it seems Ogg keeps track of a packet's size at the byte level, rather than at the bit level (eg, if I encode a packet with just one bit, decode will think there are 8 bits available). Am I right ? Not that it's a particularly important issue, since remaining bits will probably be initialized, but I noticed this while adding some calls to oggpack_look1 at the end of my decode routines

Hi, It seems the oggz-comment on your computer has more features than the one you sent in August :-) Any chance you could send a more recent copy? In any case, I've updated the --help output for the -s option, and also added a manual page with the same info, in doc/oggz-comment.1.sgml (in svn.annodex.net changeset:3280). cheers, Conrad. On 07/11/2007, Kangyuan Niu

> Besides, this is something that is very easy to implement for > systems which aren't C99. Good point. > IMO, its less ugly than the cast, but only just. Fair enough, maybe I can just parse casts as second nature, which is a scary thought :) I'll post an updated patch soon with the C99 macros instead.

Hi, Language should be Content-Language to match other uses, and while there I think Category might as well become Content-Category too, though this one doesn't "exist" AFAIK. I'm pretty sure these things come from some standard, but I have no idea where, so if you know, feel free to point my in the right direction. Cheers -------------- next part -------------- A non-text

if they are in different directories. -------------- next part -------------- A non-text attachment was scrubbed... Name: oggzdiff.fifo.diff Type: text/x-patch Size: 399 bytes Desc: not available Url : http://lists.xiph.org/pipermail/ogg-dev/attachments/20080630/c2743386/attachment.bin

Hi, this patch adds dirac.c as a source file to the oggz tools, rather than a lib. The previous would try to compile at link time, and would not include the right -I flags, and this will fail when including config.h in dirac.c (which will be needed when someone else posts a patch to get liboggz to build on win32). I'm not toally sure why dirac.c isn't just in the sources in liboggz rather

> looks good, but I get many hunk failures when applying the patch, even > with fuzz level 3. > > Could you please regenerate the patch using "svn diff"? Hmm, that's curious, I actually generated the patch (using svn diff IIRC) as Barry had the 'patch contains the whole file' problem (due to newline issues, presumably). Here it is again, against latest svn, with

2008/11/21 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-21, Conrad Parker <conrad at metadecks.org> wrote: >> 2008/11/15 David Flynn <davidf+nntp at woaf.net>: >>> On 2008-11-14, Conrad Parker <conrad at metadecks.org> wrote: >>>> It seems oggz chop, merge and sort will need some attention to deal >>>> with the Dirac