similar to: Problems seeking with liboggz

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

-----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

I'm no expert, but it sounds to me like normal variable bitrate stream behaviour. With variable bit rate, you cannot calculate exact byte address from time reference. So, in general you estimate and get close to time reference requested. Whenever you need precise pocision, you should use constant bit rate or a byte offset (instead of time/milliseconds). FYI, in my apps, I use time to show

Hi, I have a problem. I've started to develop crossplatform sound receiving application using qt4/openal/libfishsound. Server is streaming audio coded with speex in ogg container throuh http. I'm receiving packages and when I write them to file application example from libfishsound is properly decoding it. Problem starts, when I want to decode from memory, for example: receive few

Just an attempt to avoid overflows with an explicit check, I don't know if there's a better way to identify corrupt input here. James Zern (2): op_pcm_seek: fix int64 overflow op_fetch_and_process_page: fix int64 overflow src/opusfile.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) -- 2.15.0.448.gf294e3d99a-goog

Hi, I am using oggz-chop in the ubuntu jaunty, am I doing something wrong? $ oggz-chop -o yt1.ogv -s0 -e500 ondrej.ogv Segmentation fault gdb session doesn't reveal much, since it isn't compiled with debugging symbols: (gdb) bt #0 0x00007f9e5d2f0092 in memcpy () from /lib/libc.so.6 #1 0x0000000000403698 in ?? () #2 0x000000000040262e in ?? () #3 0x000000000040285d in ?? () #4

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

> 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

Greetings one and all; I'm not subscribed to this list so I'm first sending this message to verify that mails from me make it through, and then later I'll send the juicy messages with patches. Also, the address I'm using is IPv6-only and doesn't often work, so drop me from any replies and I'll catch the archives, or drop only the hostname part to get an IPv4 address that

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)

Hi, I've added kate support to liboggplay (a prerequisite to getting kate tracks to work with the mozilla plugin, which I've now got working on Linux). In addition to the Kate code: - a new oggplay-uninstalled.pc file - configure.ac checks for C++ compiler - no check for fishsound version - it wanted 0.8.0, but the svn itself was 0.7.1 !? - don't use imlib2 (nor dump-first-frame) if

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;

(i hope this is correct m.list) Hi, there is a small compiling problem for mingw when compiling on libogg.. in include/ogg/os_types.h : ogg_int64_t, ogg_int32_t, etc are defined correctly on cygwin and MSVC/Borland but not on mingw... i have attached a patch that will fix this problem (i hope it attaches correctly) thx, Nehal --- os_types.h.old Fri Jul 19 02:25:52 2002 +++ os_types.h Tue

Hello Conrad, I'm trying to seek the way you told but I'm facing a problem. ogg_page_packets returns 164 and following code returns 189. Shouldn't it be the same, what does that means ? int res; while (true) { res = ogg_stream_packetout(&os, &op); if (res == 1) nPackets++; if (res == -1)

On Tue, Nov 28, 2017 at 3:22 PM, James Zern <jzern at google.com> wrote: > On Mon, Nov 20, 2017 at 1:07 PM, James Zern <jzern at google.com> wrote: >> Just an attempt to avoid overflows with an explicit check, I don't know if >> there's a better way to identify corrupt input here. >> >> James Zern (2): >> op_pcm_seek: fix int64 overflow

Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://westfish.xiph.org/pipermail/vorbis-dev/attachments/20040618/e7bee431/attachment.pgp

Hi, I was wondering what oggz_get_bos and oggz_get_eos are supposed to do, specifically are they meant to be used in oggz_read mode? The documentation says "Determine if a given logical bitstream is at [bos/eos]". However if get_bos is given a specific serialno it returns that stream's b_o_s flag which, in read mode, is set on initialisation. The serialno=-1 (for all streams)

??????? I've rewritten my theora player using liboggz. I've stumbled upon a few issues though. First of all liboggz exposes oggz_read and oggz_run, but how can i read only sound data, or only video data using liboggz, say something like this: oggz_read_sound(1024), oggz_read_video(1024). ? ? ? ?? Second of all i tried using liboggz's seek function. Immediately after the seek i get some

> Since these are the only two uses of int64_t instead of ogg_int64_t in > liboggz, please commit. In svn. Didn't get the OK from Conrad from committing to his software, hope it's OK kfish ^_^