similar to: Storing RTP in Ogg

On Wed, Jan 03, 2007 at 03:47:38PM +1300, Andrew Donkin wrote: > My original plan was to store one RTP packet per ogg packet, one packet > per page, with the granule position of the page to the arrival time > of the RTP packet, and metadata in a custom format in the BOS packet. That's fine. SSRC as stream serialno? Note that by using arrival time as the granulepos you're making

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

So, I abandoned the hope of using the ogg python bindings to do pure ogg container encoding. I started looking at the libogg in the hopes of retooling the bindings to follow a better object model and it actually looks like the problem is down in libogg, not the bindings. Am I crazy or does libogg rely on libvorbis to return ogg_packets, and that there are no functions that will build an ogg_packet

On 02/05/07, Elaine YueLien <et@ihear.com> wrote: > Hi, > > Several months ago, I asked a question about seeking without a metric. > You can find one answer in this beta release, demonstrated in the > example program multiThreadSeek. There is also an example demuxer, and a > rewriter. Hi Elaine, congratulations :-) that's a nicely designed API you've got there.

On 15-Feb-08, at 6:44 AM, ogg.k.ogg.k@googlemail.com wrote: > Well, it doesn't quite work because the second part of the gpos is > an offset, > rather than absolute, and the precision we shed on one, we need to > recover > on the other one, to keep the ability to timestamp events at the > correct > granularity. It would have worked if the second part was absolute

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

Hi, I have a question about seeking. In fact, it's more or less a kind of rambling and thinking aloud, circling around a question. I've been wondering how to deal with seeking in a stream, and what to do when seeking in the middle of a set of active events (eg, when several bits of text are supposed to be shown, but you seek after the time when they are first shown, and before the time

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

Dear all I'm aware that there have been several discussions about the seeking issue and I'm sorry to bring this up again. To solve the problem with Inter-Frame garbage, a seek to the previous keyframe has to be made. The keyframe number should be extracted from the granulepos of the frame where we want to seek to. I hope I understood the theory - unfortunately a few questions have

dear list, i am trying to write a small program which reads an ogg file and writes it to another ogg file (and changes serial number, granulepos etc on the fly). reading the ogg file is ok (ogg_sync_pageout, ogg_stream_pagein, ogg_stream_packetout). but writing the file doesn't work - the granulepos and page structures don't match with the original file. here's what i am doing.

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

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

2009/6/18 Adam Rosi-Kessel <adam at rosi-kessel.org>: > On Thu, Jun 18, 2009 at 11:12:30PM +0900, Conrad Parker wrote: >> yow, that's pretty badly corrupted, the vorbis codebooks (usually the >> third packet) is completely gone. It looks like you'd need to throw >> away the first 16 packets, start with fresh headers, and copy in the >> rest of the data

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 >

Can I fix the checksum with a hex editor? Sent from my iPhone On Jun 25, 2009, at 3:23 PM, Monty Montgomery <monty at xiph.org> wrote: > Confirmed--- the checksum on the second page (the comment page where > the album art was added) is incorrect. Vorbis players are not allowed > to decode any stream in which one of the setup headers is corrupt, and > a bad checksum counts as

On 23/02/15 10:30 AM, Tony wrote: > I __think__ opus-tools' opusenc has code which can be used as a > template/sample for how to create an .Ogg file with Opus content. As > expected, it makes use of libopus and libogg. Sadly that's the best option currently. As you say it's a bit complicated, although oggenc has a lot of extra support for controlling encoder options you

I have a technical question about the vorbis granule position, but I would like to put the question into context. When a ogg vorbis stream is ripped using wget, fetch, or streamripper under Linux or FreeBSD, the resulting file has problems both with granule position and with a missing EOS. I think I can figure out how to add an EOS, but is there a way to determine the granule position in a stream

> any new fields. However, I cannot even find Dirac in oggz > http://git.xiph.org/?p=liboggz.git;a=blob;f=src/liboggz/oggz_auto.h; There's dirac.[ch] in the tools directory, though I haven't looked at what's in there. Not sure why it's segregated like that.

On Sat, 2006-07-15 at 14:35 -0700, Ralph Giles wrote: > On Sat, Jul 15, 2006 at 02:17:22PM -0500, Joe Wreschnig wrote: > > > I'm working on support for tagging Speex files for Mutagen[0] and part > > of the specification at [1] is confusing me. It says the first page > > should have granulepos 0 and packetno 0. Does this really mean page > > sequence number 0,