similar to: Fwd: final changes to mimetypes rfc

Excellent, thanks for noticing - will add that. Also: question about the Dirac codec identifier in Ogg. It is currently char[5]: 'BBCD\0' - but in your spec it is char[4]: 'BBCD'. Which one should we put in? Cheers, Silvia. On Sat, Aug 16, 2008 at 5:31 PM, David Flynn <davidf+nntp at woaf.net> wrote: > On 2008-08-16, Ralph Giles <giles at xiph.org> wrote:

Hi all, 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!). If you have anything in need of change, speak up now. I have one question in particular: Ogg.k.ogg.k: is the kate codec parameter now down to 8 bytes? If so, it's ok, since I've already made that change. Cheers, Silvia.

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

2008/5/29 Ralph Giles <giles at xiph.org>: > On 28-May-08, at 6:20 PM, Conrad Parker wrote: > >> /* TODO: this should check against 42 for the relevant version numbers */ >> if (op->bytes < 41) return 0; > > I gather this means the USE_THEORA_PRE_ALPHA_3_FORMAT #if should instead be > based on the length of the header packet. I'm not sure why you're

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 >

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 header

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

2008/11/24 David Flynn <davidf+nntp at woaf.net>: > On a slightly unrelated note, i keep hitting the following error in > liboggz when using the oggz tools on an ogg dirac stream: > > /home/davidf/project/liboggz/src/liboggz/oggz.c:202: oggz_close: > Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed. > > I'll supply an example file tomorrow if that

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

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, }; +

On Sat, Aug 16, 2008 at 12:23 AM, Silvia Pfeiffer wrote: > Have we got a spec? If not, we may want to remove it altogether and > make the fixes in our wiki as the spec develops. We have a draft spec with no implementation. I can't imagine the magic changing, so I think it's ok to leave it in, but I'm ok to remove it if you think that's best. I do think there's little

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

On Fri, Aug 15, 2008 at 8:42 PM, Ian Malone <ibmalone at gmail.com> wrote: > 2008/8/15 Silvia Pfeiffer <silviapfeiffer1 at gmail.com>: >> Hi all, >> >> 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!). >> >> If you have anything in need of change,

On 8/17/08, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote: > OK, then yuv4mpeg will have the magic number: char[8]: 'YUV4MPEG'. Which was previously for those not paying attention char[9]: 'YUV4MPEG2'. > Also, can you put the link to the spec into > http://wiki.xiph.org/index.php/MIMETypesCodecs ? AFAIK, that is just a matter of putting a [[OggUVS]] in

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,

On 17-Aug-08, at 1:11 AM, Silvia Pfeiffer wrote: > OK, then yuv4mpeg will have the magic number: char[8]: 'YUV4MPEG'. > Is that ok? Yes, I'm good with that. > Also, can you put the link to the spec into > http://wiki.xiph.org/index.php/MIMETypesCodecs ? Thanks! Sorry, I thought I'd dumped the spec into the wiki. It's there now, and linked from the

On 11/14/08, David Flynn <davidf+nntp at woaf.net> wrote: > Correct; there is no metadata handling capability in the current > mapping spec. I'd suggest at some point to look into separate stream solution for metadata, perhaps M3F [1]. -Ivo [1] http://wiki.xiph.org/index.php/M3F

The definition of granule position for an OggDirac elementary stream isn't the same as theora. Index: tools/oggz_tools.c =================================================================== --- tools/oggz_tools.c (revision 3759) +++ tools/oggz_tools.c (working copy) @@ -454,7 +454,15 @@ iframe = granulepos >> granuleshift; pframe = granulepos - (iframe << granuleshift);

Hello list, We have recently introduced the codecs (optional) parameter on the Ogg media types for easier identification of encapsulated codecs in conditions were it's not feasable to examine the streams directly. I received a comment from the IESG that we should have some sort of list to describe how Ogg mapping strings translate to codec parameter strings, so I went ahead and compiled a

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