similar to: Fwd: Skeleton 4.0 draft, help with Dirac fields please!

Chris Pearce wrote: > Hi Guys & Gals, > > I need you guys to decide whether we want to include extra granulepos > fields to Skeleton 4. Given the underwhelming discussion regarding this, > I'm guessing the need and/or desire for these fields isn't really there. I haven't commented mostly because I don't know what Monty's plans for a "grand unified

On Tue, Jun 1, 2010 at 12:56 PM, Monty Montgomery <monty at xiph.org> wrote: > On Mon, May 31, 2010 at 10:51 PM, Timothy B. Terriberry > <tterribe at email.unc.edu> wrote: >> Chris Pearce wrote: >>> ? Hi Guys & Gals, >>> >>> I need you guys to decide whether we want to include extra granulepos >>> fields to Skeleton 4. Given the

On 31 May 2010 20:51, Chris Pearce <chris at pearce.org.nz> wrote: > Ok, thanks Silvia. I'll keep working on OggIndex/Skeleton 4.0 without > the new granulepos fields, and if they're ready in time I'll include > them, otherwise they can wait until Skeleton 4.x. I was waiting for Monty so summarize his ideas too, but from the irc discussion, it sounds like the extra

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

Hi everybody, I've updated OggIndex to now output Skeleton 4.0 tracks. The differences between Skeleton 3.x and Skeleton 4.0 with OggIndex is: * The fisbone packet now includes a "Radix" field. * The fisbone packet now includes two new compulsory message headers; "Role" and "Name". * The fishead packet no longer includes "start time"

On Thu, Feb 28, 2008 at 1:53 AM, Ralph Giles <giles@xiph.org> wrote: > On 27-Feb-08, at 10:44 PM, Conrad Parker wrote: > > > Sure: I'm thinking about Ogg demuxers and seeking implementations. > > These need to know the framerate in order to be able to interpret the > > granulepos in terms of time. If they did not have to extract that from > > the

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

I've been looking over Benjamin Schwartz's Skeleton A-mod proposal. I've been pretty busy with other projects over the past few months, so haven't had a chance to look at Ogg indexing until now... In general, I think Benjamin's ideas are sound, they're improvements, and I'm open to being convinced to take them in the next index version. We may as well get the index

On Sat, 23 Aug 2014, Silvia Pfeiffer wrote: > What does oggz-info tell you about the file when you've merged it > (without skeleton)? It may say that there are two logical video > bitstreams, because they've come from different files. So, two > skeletons may actually be correct. There should be (and are) two logical video streams - I'm trying to create a file with a

I've developed an indexer which embeds a keyframe index track in Ogg files. It embeds the index in its own track, so that players that don't understand or don't want to use the index can just ignore it. Ogg needs this to make seeking over networks faster and more efficient. Currently we must do a bisection search when seeking, which usually takes aound 6 HTTP requests, give or

On Sat, 23 Aug 2014, Silvia Pfeiffer wrote: > I would merge them with oggz-merge without skeleton and then add > skeleton using oggindex e.g. > http://git.xiph.org/?p=OggIndex.git;a=summary . (oggindex is also > available from http://firefogg.org/nightly/ ) Ah, that looks like the tool I was looking for! Nearly there now... With a theora+speex file, or a theora+opus file, it

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

On Fri, Jun 5, 2009 at 4:30 AM, ogg.k.ogg.k at googlemail.com <ogg.k.ogg.k at googlemail.com> wrote: > It holds the granulerate, so it'd allow this for those codecs that use the > granule shift way of encoding their granules (except for those pages > where no packet ends, as these will have no granpos set). BTW, we need to add another field out of the remaining reserved bits

I'm happy with it. How are you creating the new message header fields? A default role of audio/main and video/main on the first tracks? And a default of "audio_1" and "video_1" on the name? Or is it enforced as parameters on the command line? Cheers, Silvia. On Fri, Jun 11, 2010 at 10:16 AM, Chris Pearce <chris at pearce.org.nz> wrote: > ?Hey all, > >

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

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

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 >

On 2008-11-14, Conrad Parker <conrad at metadecks.org> wrote: > Should oggz-comment be modified to disallow modification of Dirac > streams, ie. does Ogg Dirac never contain VorbisComment metadata? Correct; there is no metadata handling capability in the current mapping spec. > It seems oggz chop, merge and sort will need some attention to deal > with the Dirac granulepos and

On Thu, Nov 13, 2008 at 06:06:10PM +0900, Conrad Parker wrote: > 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 to a bugtracker where they are reported. eg. I mostly meant what you apparently

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