similar to: VC6 Patch

I have tried to add a plunging to the "libtheora-1.0beta2" (network bandwidth measuring component was added) and Got it success for some far now the problem is when it is added the encoding process get extremely slow (around 20 seconds delay). I think that the problem is with my modified Makefile (some flag may have missed). the following is my modified Makefile.am which is in the

I have tried to add a plunging to the "libtheora-1.0beta2" (network bandwidth measuring component was added) and Got it success for some far now the problem is when it is added the encoding process get extremely slow (around 20 seconds delay). I think that the problem is with my modified Makefile (some flag may have missed). the following is my modified Makefile.am which is in the

I'm getting errors like so on initial build of libtheora - 1>c1 : fatal error C1083: Cannot open source file: '..\lib\dec\x86_vc\x86stat.c': No such file or directory 1> mmxstate.c (TaskId:16) 1>c1 : fatal error C1083: Cannot open source file: '..\lib\dec\x86_vc\mmxstate.c': No such file or directory 1> mmxloopfilter.c (TaskId:16) 1>c1 : fatal error C1083:

Hi all, I've patched theora-mmx to build on x86_64. The patch against SVN is attached. Basically all I did was to copy lib/i386 to lib/x86_64 and tweak the assembler code a bit: * added to each file: typedef unsigned long int ogg_uint64_t * converted all asm inputs to 64-bit in: dsp_mmxext.c, fdct_mmx.c, recon_mmx.c * left all asm outputs at 32-bit * I didn't patch dsp_mmx.c, since all

quite some speed improvement indeed. attached the updated patch to apply to svn/trunk. j -------------- next part -------------- A non-text attachment was scrubbed... Name: theora-mmx.patch.gz Type: application/x-gzip Size: 8648 bytes Desc: not available Url : http://lists.xiph.org/pipermail/theora-dev/attachments/20040824/5a5f2731/theora-mmx.patch-0001.bin

Hi Guys, I've been working on speeding up seeking in Ogg playback in for the video element in Firefox. This is Mozilla bug 469408: https://bugzilla.mozilla.org/show_bug.cgi?id=469408 When liboggz seeks, it basically does a bisection search through the media, looking for an Ogg page with the target seek time. This is fine for files stored locally, but when the file is stored on a web server,

[I'm not online regularly, so don't include me in any replies. Looks like the archives are working at present, so I'll catch up from them when I get a chance. Thanks...] (Trying out vorbis-dev@ instead of vorbis@ where I sent my previous messages; if this is the wrong place, correct me) Greetings. Some weeks ago, I submitted several hacks which gave me the ability to play Ogg

-----Original Message----- From: Julio Cesar Esteves Cabezas [mailto:jcabezas at inovax.com.br] Sent: segunda-feira, 21 de maio de 2012 20:29 To: 'Conrad Parker' Subject: RE: [ogg-dev] Problems seeking with liboggz Hi, Attached goes MyAudio.spx. Julio. -----Original Message----- From: conrad.parker at gmail.com [mailto:conrad.parker at gmail.com] On Behalf Of Conrad Parker Sent:

Hi, Any insights about the cause of failure of time seek in liboggz, as shown in previous posts ? Thanks, Julio. -----Original Message----- From: Julio Cesar Esteves Cabezas [mailto:jcabezas at inovax.com.br] Sent: segunda-feira, 21 de maio de 2012 20:29 To: 'Conrad Parker' Subject: RE: [ogg-dev] Problems seeking with liboggz Hi, Attached goes MyAudio.spx. Julio. -----Original

Hi, The Ogg-Speex test file I used is CBR. I am sure of that by running oggz-dump on the file and confirming that all audio packets have 38 bytes; that means (for narrowband) a constant 15 Kbps. I wrote a very basic test program in Visual Studio 2010 that demonstrates the strange behaviour I mentioned. The output shows that the audio file has 8 pages, 6 of them

Hi, Today I tried to run my player code with the CVS libvorbis (instead of RC3 as usual) and I found the infinite loop here (lines prefixed with >> are in the loop): tatic ogg_int64_t _get_prev_page(OggVorbis_File *vf,ogg_page *og){ ogg_int64_t begin=vf->offset; ogg_int64_t end=begin; ogg_int64_t ret; ogg_int64_t offset=-1; >> while(offset==-1){ >>

Hi there, First of all, sorry for my English I'm not a native english speaker. I need to develop and application witch does 3 tasks with oggs files : 1/ chain 2 ogg files 2/ extract a part from an ogg file 3/ add silence between two chained oggs files. Basically, - For the 1st task, I think that the best way to chain ogg files is to use the "cat" (on linux) or "copy

I have a 1.1G Ogg file with vorbis and theora. oggz_seek_units() takes 14 seconds to find a position in the file towards the end. Now, the function guess() in oggz_seek() guesses a position at about 1.5G and then slowly searches back until it finds the end of the file (continously seeking beyond the end of the file and then calling read which returns 0). Then it does a linear scan from the

In file vorbisfile.c, function int ov_pcm_seek_page(OggVorbis_File *vf,ogg_int64_t pos) the calculation of the approximate seek point causes an overflow for very large files and on pure 32 bit architectures. /* take a (pretty decent) guess. */ bisect=begin + (target-begintime)*(end-begin)/(endtime-begintime) - CHUNKSIZE; The temporary expression (target-begintime)*(end-begin)

Good day. It seems vorbisfile has a bug. There is a such string in ov_time_seek: ogg_int64_t target=pcm_total+(seconds-time_total)*vf->vi[link].rate; It is not accounted type convertion between double and ogg_int64_t. E.g. if I convert 440267'th sample (44100Hz source) to time: double dSec = 440267 / (double) 44100; and then try to seek dSec: ov_time_seek(pOVFile, dSec); the resulting

This time in vcut: vorbis-tools/vcut/vcut.h:23 and 24. No, I'm not spending quality time with grep; I'm trying to compile vorbis with the native Sun Forte compilers. Much badness, of which these // issues are only part. :-( More details to follow... Patch/inc/lazy. {+} Jeff Squyres {+} squyres@cse.nd.edu {+} Perpetual Obsessive Notre Dame Student Craving Utter Madness {+} "I

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;

> There seems to be some inconsistency in the changes to the type of > sample_in_record and its accessor: the field was changed from int to > ogg_int64_t in src/liboggplay/oggplay_callback_info.h, and the return > type of the accessor function was changed from int to long in the > corresponding .c file and public header. Having heard no more about this, I'll make a patch that

hi, i was trying to enable the mmx code on mac os x. to get to that point one has to replace some inline assembler code: .balign 16 -> .p2align 4 and replace .rept .. .endr with #defines. but to makes things more complicated apple's GAS does not support movsx instructions and thus the following line does not work: " movsx %%di, %%edi \n\t" [ more details at

Hello, This is the code, it's a little crap but only to see if it works. I assume rate = 16000 and frame_size = 320. if (this->seek_to != -1) // SKIP { ogg_int64_t max_units; //max_units = speex_seek(fin, this->seek_to, 0, rate); int nPages = 0; int nPackets = 0; // Pone el cursor en la posici?n inicial del fichero fseek(fin, 0, SEEK_SET);