Displaying 20 results from an estimated 400 matches similar to: "Problems seeking with liboggz"
2012 May 21
0
Problems seeking with liboggz
-----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:
2012 May 21
1
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
2012 May 16
2
Problems seeking with liboggz
Hi,
I intend to use Ogg+Speex for voice recording/playback in a VoIP app.
I am experimenting with liboggz to get acquainted with its API.
As test files I am using some Ogg-Speex files converted from WAV files
with speexenc.exe.
I wrote a little testing app in Visual Studio 2010 under Windows 7.
I defined OggzReadPage and OggzReadPacket callbacks with
oggz_set_read_page()
2012 May 17
0
Problems seeking with liboggz
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
2009 May 15
0
[PATCH] oggz: limit seeking to specified range
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,
2007 Oct 09
1
VC6 Patch
Here is a patch that gets the theora_static.dsp project for VC6 building
again.
Aaron
-------------- next part --------------
Index: win32/theora_static.dsp
===================================================================
--- win32/theora_static.dsp (revision 13945)
+++ win32/theora_static.dsp (working copy)
@@ -41,7 +41,7 @@
# PROP Intermediate_Dir "Static_Release"
# PROP
2004 Sep 06
1
Fixing libvorbisfile to handle largefiles
[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
2002 Mar 27
0
CVS libvorbisfile
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){
>>
2009 Aug 12
1
Oggz use
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
2009 May 04
1
[PATCH] oggz: inefficient seeking
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
2009 Feb 08
1
[libvorbis] Bugfix: seek broken for large files and on pure 32 bit architectures
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)
2002 Sep 25
0
vorbisfile bug?
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
2001 Aug 20
1
Still more // comments
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
2008 Dec 16
3
liboggz: use ogg_int64_t instead of C99 int64_t for the benefit of you-can-guess-who
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;
2008 May 01
2
[PATCH] liboggplay - kate support, build fixes, and misc
> 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
2009 May 16
1
Speex seek with high precision
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);
2008 Nov 04
1
[PATCH] liboggz: Update Dirac granulepos definition
The definition of granule position for an OggDirac elementary stream
isn't the same as theora.
Index: tools/oggz_tools.c
===================================================================
--- tools/oggz_tools.c (revision 3759)
+++ tools/oggz_tools.c (working copy)
@@ -454,7 +454,15 @@
iframe = granulepos >> granuleshift;
pframe = granulepos - (iframe << granuleshift);
2005 May 26
1
libogg2 branch->trunk (deadline: 5/30)
Ok guys and gals
Monty assigned me as libogg2 maintainer a few weeks ago, with the
provision that I get consensus on API changes from everyone. In order
to facilitate discussion, and to "move on" vs letting this stalemate
hold development at a stand still, I'm setting an initial deadline of
this comming Monday, May 30th.
If nobody has a strong objection why these API changes
2005 May 26
1
libogg2 branch->trunk (deadline: 5/30)
Ok guys and gals
Monty assigned me as libogg2 maintainer a few weeks ago, with the
provision that I get consensus on API changes from everyone. In order
to facilitate discussion, and to "move on" vs letting this stalemate
hold development at a stand still, I'm setting an initial deadline of
this comming Monday, May 30th.
If nobody has a strong objection why these API changes
2005 May 26
1
libogg2 branch->trunk (deadline: 5/30)
Ok guys and gals
Monty assigned me as libogg2 maintainer a few weeks ago, with the
provision that I get consensus on API changes from everyone. In order
to facilitate discussion, and to "move on" vs letting this stalemate
hold development at a stand still, I'm setting an initial deadline of
this comming Monday, May 30th.
If nobody has a strong objection why these API changes