search for: dirac

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

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

Cross-posting from schrodinger-devel. Please follow up there, since the implementors aren't on ogg-dev. -r Begin forwarded message: From: Ralph Giles <giles@xiph.org> Date: February 27, 2008 5:26:07 PM PST (CA) Subject: [Schrodinger-devel] Updating the Ogg mapping for Dirac Several years ago I did a draft mapping[1] for encapsulating Dirac in an Ogg stream, based on an early draft of the spec. At the FOMS conference last month, Anuradha pointed out that it was out of date, several of its dependencies having changed between the 0.9 and 2.1 revisions. Specifically, th...

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

Hi, this patch adds dirac.c as a source file to the oggz tools, rather than a lib. The previous would try to compile at link time, and would not include the right -I flags, and this will fail when including config.h in dirac.c (which will be needed when someone else posts a patch to get liboggz to build on win32). I'm n...

Hi all, I am trying to set up the codecs table in the wiki and we have played a bit with Dirac to find out what existing tools write into the header. The Schroedinger implementation by Fluendo uses (or used to use) "KW-DIRAC" as the identifier in the Ogg header. "BBCD" is the identifier of each of the Dirac data packages. More recently, I read that the Dirac Sequence he...

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 discovered they were very nearly working. Aft...

Hi again, could someone tell me why there is links to Dirac on the Xiph wiki? The BBC takes care of Dirac, not Xiph? Is Xiph just a promoter? Secondly, how would one choose to save the video in a lossless format with Dirac, is there some interface (like a switch) in an application for this to be achieved? -- Using Opera's revolutionary e-mail...

On Thu, Aug 14, 2008 at 9:14 PM, Silvia Pfeiffer wrote: > The IETF has a final draft of our RFC at > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5334.txt (yes, it goes > from 3534 to 5334 - funny!). Didn't we decide YUV4MPEG should be 8 octets as well? -r

On 10 May 2010 23:20, Chris Pearce <chris at pearce.org.nz> wrote: > The granulepos radix was something that Conrad and Ralph were talking about > at FOMS2010. I don't know how it's supposed to be used, or why we need it. > It was supposed to be needed for Dirac? Maybe Ralph or Conrad can remember? > If not, we should remove it. There's no point in adding a poorly spec'd > field that no one will use. Right, so adding the 'granulepos radix' was based on my recollection of a draft of the Ogg Dirac mapping. That version split the granlu...

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 dependency ordering, so let's leave...

> 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 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 fixed below, namely, showing pt, dt, dist, and delay. > conrad at chichai:~/share/dirac$ oggz dump -c dirac sage-640x360.ogg > |grep g...

...;> "grand unified granpos scheme" are. All of this is mostly in his head >> right now, and he needs to be the one to provide feedback. > > I've been trying to write it down such that it is clear or not if I > understand everything I need to (especially in the case of dirac). ?Up > to this point I haven't, thus my lack of delivery. I don't think getting Ogg in shape for Dirac delivery is that much of a priority right now to have Firefox blocked on it. I think Chris Pearce should go ahead without these fields. There is always time for another skeleton revis...

...nd 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 implementing that. Around a year and a > half ago, it began adding the KW-DIRAC stream identifier manually, > since the encoder wasn't producing it any more, followed by the > framerate stored as a rational pair of 32 bit big endian integers, > and using *that* as the bos packet. The demuxer would then strip and > discard this before passing the remaining d...

Quite a while ago, the specification was modified to change the way the nondefault scan format was signalled; this patch fixes that. Index: liboggz/dirac.c =================================================================== --- liboggz/dirac.c (revision 3759) +++ liboggz/dirac.c (working copy) @@ -122,6 +122,10 @@ 1, 9, 10, 9, 10, 9, 10, 4, 3, 7, 6, 4, 3, 7, 6, 2, 2, 7, 6, 7, 6, }; + static const int dirac_top_field_first[] = { /* extract...

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

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

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

...p://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, 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...