similar to: Header packet multiplicity

> 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

On 12-Feb-08, at 4:49 AM, ogg.k.ogg.k@googlemail.com wrote: > Has anyone thoughts on whether multiple header packets are a good > idea ? > I currently have a header per "type" of data, and I'm now at 9 > headers. The > original idea was to make it harder to hit a maximum limit, but I've > since realized > that the 64 KB (ish) limit is on pages, rather

> speex and flac have an "extra headers" field in the bos page, and > skeleton also has a field for recording the total number of headers > (as it's kinda important for editing files). If you know how many > headers there are going to be at the start of encoding, then adding a > field like that might be enough. I do know at start, and I have such a field too. However,

> It's nice if the first header is small, because it lets you find the > beginning-of-stream (bos) packets for all the streams quickly, > ideally within a single read buffer, so you can configure the decoder > pipeline. Currently the bos headers we have for codecs in Ogg are all > less than 100 bytes. Same for me, all good here. > Otherwise, I don't suppose it matters

While testing the new vcut, some of the early results had badly framed headers. I actually didn't notice it at first, because I was testing with oggz-validate, but ogginfo does identify the problem: "WARNING: Vorbis stream X does not have headers correctly framed. Terminal header page contains additional packets or has non-zero granulepos" Conrad (or someone else) may want to

On 14/02/2008, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > Ralph wrote: > > Conrad, does this work for the other codecs as well? I vaguely > > remember libvorbis putting -1 on the header packets instead of 0. > > AFAIK, it's 0, -1 being for partial pages, from the ogg docs. -1 (or, I > suppose all negative values, but I'm not sure) mean

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

On Fri, Jul 17, 2009 at 12:48:27PM -0700, Ralph Giles wrote: > > In my ongoing quest to restore corrupted ogg files, I'm trying to find > > an easy way to identify the setup header without having to actually > > decode it. I understand that it starts with [packet_type] = 5 and then > > the string 'vorbis', but is there some way to figure out where it > >

On 13-Feb-08, at 3:40 AM, ogg.k.ogg.k@googlemail.com wrote: > However, I was concerned about the RTP streaming case, where packets > may be lost, and the "other" container case, where they have to be > concatenated (and thus one needs a way to walk past them easily). > I reckon I'll just add a "header length" to headers past the first > one, and > maybe

2008/11/26 David Flynn <davidf+nntp at woaf.net>: >>>> http://trac.annodex.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,

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.

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

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

Hello, > (1) Split the content into chain segments > (2) extract the first and last data packet from each segment, for all tracks > (3) recover / calculate the granulepos values for the first and last data packets (*) > (4) convert the granulepos values from the first and last data packets into time values > (5) take the largest difference between start and end time as the total

On 28/02/2008, Ralph Giles <giles@xiph.org> wrote: > Conrad had suggested instead extending the now Ogg-specific initial > data to include the framerate (and possibly also frame size) since > these are somewhat tedious to parse out of the sequence header. It > turns out that gstreamer (the test framework everyone's been using > with schroedinger) was already

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

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 Fri, Nov 14, 2008 at 5:11 AM, Hans J. Koch <hjk at linutronix.de> wrote: >> I don't think anything currently in Ogg can do this. The closest I can >> think of is CMML's clip concept, but you'd still have to parse the entire >> stream to find them all. > > That's nearly useless for DVD-like applications. I don't know. Wouldn't it work if

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

I'm starting with the theora player_example.c. I want to be able to determine the duration of the audio/video ahead of time, to be able to display it somewhere. I can't see anything obvious in ogg.h, theora.h, or vorbis.h for this. Can anyone help me with the right place to look to do this? Thanks, Ken Larson FMJ project, fmj.sourceforge.net