similar to: cheap way of getting number of frames in an ogg_page?

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.

hi, in my quest to grok ogg i tried to write a small program which extracts ogg_packets, and stuffs them back into ogg pages (which are then written to a file). extracting the packets works fine, but i have problems stuffing them into a new ogg stream. pseudo code: ogg_stream_init(os, serialno) foreach p in packets: ogg_stream_packetin(os, p) // try to extract a page

Hi. I assume that I am deeply stupid and have missed something obvious, but why does this bare-bones code not generate a valid (If trivial) opus file? Running opusinfo I ge the following which I interpret this to mean that not even the first packet gets a pass: New logical stream (#1, serial: 1f0cce42): type opus WARNING: Could not decode Opus header packet 0 - invalid Opus stream (1) WARNING:

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

Ups! Maybe it's time somebody corrected that statement then - the wiki seems the right place to put the correct algorithm, IMHO. Cheers, Silvia. On Feb 13, 2008 10:06 AM, Ralph Giles <ralph.giles@artifex.com> wrote: > > On 12-Feb-08, at 2:57 PM, Ralph Giles wrote: > > > http://wiki.xiph.org/index.php/GranulePosAndSeeking > > I'm not sure it's helpful to

Hi all, something which came up recently in relation to the design of Kate's granulepos was whether or not the granulepos of successive Ogg pages is allowed to be the same, ie. whether or not granulepos must be strictly increasing. As this question is more generally about Ogg granulepos, how about we answer it first and then get back to the discussion of Kate's granulepos ... Here is

> No particular answers, but I can at least point out that the way > things were designed for CMML was to work with the existing Ogg > seeking algorithm. The idea is that a generic seeking routine can work > on any Ogg file, as long as it knows the granulepos->time mapping for > the logical bitstreams in the file. That's why all the > timestamp-related info is crammed into

> The advantage of storing this in the granulepos field itself, like > theora and CMML do, is that the seek code may already understand how > to handle the back pointer. Right now everything assumes the mapping > is from 'initialized decoder' + 'granulepos from page header' => > timestamp, or in the case of theora and CMML => 'timestamp' + 'last

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,

David Flynn has proposed a new Ogg Dirac mapping. The draft is here: http://davidf.woaf.net/dirac-mapping-ogg.pdf This is a much bigger break from other codecs than my draft (at http://wiki.xiph.org/index.php/OggDirac). We talked a bit about it on IRC today. Below is my summary; hopefully David can correct anything I got wrong or misleading. Comments? There are two main differences

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

2008/10/29 Romain Beauxis <toots at rastageeks.org>: > > I am currently implementing theora for our application. > In our model for generating ogg streams, we may want to stop > a stream while not providing a new YUV data buffer for encoding. > > Current API doesn't allow such thing, since the eos flag is set by the > packetout function only when the last_p parameter

Hi, I've seen several implementations of Ogg demuxing that use a zero granulepos to detect headers. However, I do not recall seeing this in the Ogg docs - is this an abuse that happens to work because Vorbis is timed by end granule, or is it a proper way to check ? Thanks

Hello learned ogg folks, and welcome to 2007. Sadly I am back at work already, and I'd like to seek your advice. We need to store raw RTP packets on disk as they are received from the network. There will be multiple streams of media--at least one audio and one video--that all need to go in the same file. We have decided to use ogg because it is the simplest container format that meets our

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

> It is more complex, because the granulepos is available at the page > level. Ah. Good point, I always forget about the partial page problem :( I conveniently flush pages after each data packet in my case (due to unknown/arbitrary latency), so I tend to forget easily about those. > We've generally designed the seeking algorithm so it can be > implemented without looking inside

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

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

> There are a usually lot more data packets than header packets, so > having an internal length there hurts your bitrate a lot more. Of > course, it may not be significant for an uncompressed text codec. If muxed with a video, it's insignificant (well, for my test cases). > With codecs using the 'count of decodable samples' rule to calculate > their granulepos, the