search for: granulepos

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. (python-like pseudo-code). First i create copi...

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

I've made a lot of progress on my lossless Vorbis editing project. I have a few more questions about granulepos issues I don't quite understand. granulepos is a property of Ogg pages, yet it is a field in the ogg_packet struct. When reading packets from an Ogg stream, the granulepos is set to -1 for all packets except the last packet in a page. From this I infer that - for encoding, the granulepos ne...

...odex.net/changeset/3801 >>> >>> I'll test this shortly. > > Ok, i've tested muxing some audio and video together and that works fine. > woo. great, thanks :-) So the last remaining tool to check is oggz-chop. I at first assumed it would not work with Dirac's granulepos, but it seems to do something vaguely useful: conrad at chichai:~/share/oggz-chop$ oggz chop -s 7 -e 11 -o sage-7-11.ogv ../dirac/sage-640x360.ogg conrad at chichai:~/share/oggz-chop$ oggz dump sage-7-11.ogv |grep serialno | head -n 20 00:00:00.000: serialno 1762443388, granulepos 0, packetno 0 **...

Hi While implementing OSS Ogg/Vorbis encoding and streaming using RTP/RTCP for both unicast and multicast, I have come across a few issues I need to clear out regarding the numbering of ogg_packets and their granulepos value. Below are the result for two different scenarios. <p>In the first scenario, ogg_packets are generated using a) vorbis_analysis_headerout() b) while true vorbis_analysis_buffer() vorbis_analysis_wrote() c) while true...

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

...t;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 granulepos and dependency ordering, so let's leave them >>>> for the next release. >>> >>> ok. -- may be worth having them 'warn' if they are operating on >>> something containing oggdirac. >> >> I started patching oggz sort and merge, and discove...

Jean-Marc, What exactly does the speex code do to calculate the granulepos? With vorbis it's the 'count of decodable samples including this packet'. So if you had a packet that allowed you to decode 1024 samples since the beginning of playback, the granulepos is 1024, not for example 1023 which would be the *index* of the last sample assuming C-style array...

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 > liboggz tools is required, a little more work may need to happen. Ok, let's a...

...quot;. All more complex seeking operations are a function of a higher-level layer (with knowledge of the media types and codec in use) making intelligent use of this lowest Ogg abstraction. The Ogg stream abstraction need deal with nothing more complex than 'find this page'. The various granulepos strategies for keyframes concern this last point. The basic issue with video from which complexity arises is that frames often depend on previous and possibly future frames. This happens in a larger, general category of codecs whose streams may not begin decode from just any packet as well as pac...

> 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 granulepos rather than being > placed in packet data, where it is no longer visible in the > container.. I think I'm missing something here, but I'm not qu...

I've got a question about the granulepos in speex packets. >From the speex manual (http://www.speex.org/manual2/node7.html#SECTION00073000000000000000): >The third and subsequent packets each contain one or more (number found in header) Speex frames. These are identified with packetno starting from 2 and the granulepos is the numb...

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 liboggz tools is required, a little more work may need to happen. > Here's some oggz output that...

...shown, but you seek after the time when they are first shown, and before the time when they are hidden). The three main ways I see to do this are: - The CMML way: split the granule pos in two and encode the previous clip's start granule in the low bits - this preserves the continuity of granulepos's. - The Writ way: repeat events at regular intervals, so you can always be sure to have all packets if you seek to at least that interval before the actual time you want to seek to. - adding a field in packets with the granulepos of the earliest packet still active (that's my cu...

On Fri, Dec 05, 2008 at 06:34:41AM +0900, Conrad Parker wrote: > So the last remaining tool to check is oggz-chop. I at first assumed it > would not work with Dirac's granulepos, but it seems to do something > vaguely useful: > > conrad at chichai:~/share/oggz-chop$ oggz chop -s 7 -e 11 -o > sage-7-11.ogv ../dirac/sage-640x360.ogg > conrad at chichai:~/share/oggz-chop$ oggz dump sage-7-11.ogv |grep > serialno | head -n 20 > 00:00:00.000: serialno 1762...

(Sending again after subscribing, I guess the moderator is on vacation.) 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, since the Ogg format doesn't number packets? If it doesn't mean page sequence number, what does it mean? If it does really mean packet, does that mean there are no guarantees about page/packet boundries? e.g. Vorbis guarantee...

Question: is it permissible to put more than one frame packet into a page? At 30 fps, Ogg page overhead is on the order of 8 - 10 kbits/sec. At low datarates, this is going to be unacceptable. If I shove a few frames into a page, how does this affect the granulepos stuff? ___ Dan Miller (++,) Founder, On2 Technologies <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'theora-dev-request@xiph.org' containing only the word 'unsubs...

...c), and if so could you please explain what the > problems are, or point me to a bugtracker where they are reported. eg. I mostly meant what you apparently fixed below, namely, showing pt, dt, dist, and delay. > conrad at chichai:~/share/dirac$ oggz dump -c dirac sage-640x360.ogg > |grep granulepos|head > 00:00:00.000: serialno 1763535876, granulepos > (pt:0,dt:0,dist:0,delay:0), packetno 0 *** bos: 39 bytes > 00:00:00.000: serialno 1763535876, granulepos > (pt:0,dt:4294967292,dist:0,delay:4), packetno 2: 19.658 kB > 00:00:00.166: serialno 1763535876, granulepos > (pt:8,dt:4...

...of the writing and get on with code. I'm a bit concerned about some of the multiplexing changes, specifically these paragraphs: A granule position represents the instantaneous time location between two pages. However, continuous streams and discontinuous streams differ on whether the granulepos represents the end-time of the data on a page or the start-time. Continuous streams are 'end-time' encoded; the granulepos represents the point in time immediately after the last data decoded from a page. Discontinuous streams are 'start-time' encoded; the granulepos represents...

...========================================================= --- include/ogg/ogg.h (revision 12848) +++ include/ogg/ogg.h (working copy) @@ -80,6 +80,7 @@ (which is in a seperate abstraction layer) also knows about the gap */ ogg_int64_t granulepos; + int discont; /* 0 = continuous, 1 = discontinuous */ } ogg_stream_state; @@ -176,6 +177,7 @@ /* Ogg BITSTREAM PRIMITIVES: general ***************************/ extern int ogg_stream_init(ogg_stream_state *os,int serialno); +extern int ogg_stream_setdiscont(ogg_stream_state...