similar to: Fwd: [Schrodinger-devel] Updating the Ogg mapping for Dirac

Displaying 20 results from an estimated 3000 matches similar to: "Fwd: [Schrodinger-devel] Updating the Ogg mapping for Dirac"

2008 Feb 27
2
Re: Updating the Ogg mapping for Dirac
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
2008 Jun 06
3
How Ogg mappings translate into the codecs parameter in Ogg media types
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 Nov 21
2
[Schrodinger-devel] ogg dirac granulepos in oggz tools
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
2008 Nov 14
0
[Schrodinger-devel] ogg dirac granulepos in oggz tools
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
2008 Dec 04
0
[Schrodinger-devel] ogg dirac granulepos in oggz tools
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$
2008 Nov 13
1
[Schrodinger-devel] ogg dirac granulepos in oggz tools
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 Nov 14
6
[Schrodinger-devel] ogg dirac granulepos in oggz tools
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 >
2008 Nov 21
6
ogg dirac granulepos in oggz tools
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 Nov 25
0
ogg dirac granulepos in oggz tools
>>> 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. >> My only initial concern is about the definition >> of granule_rate. My intention is to add some guidance to the oggdirac >> mapping spec on how to apply oggskeleton. This raises the slight
2008 Nov 13
0
[Schrodinger-devel] ogg dirac granulepos in oggz tools
On Thu, Nov 13, 2008 at 2:54 PM, David Flynn <davidf+nntp at woaf.net> wrote: > The only niggle i have with this file is that the EOS page has a bizare > timestamp. imho, because there is no picture in the eos page, there is > no meaningful time for it, so the granulepos should be -1 on the eos > page on the dirac logical stream. ds and I talked about this a bit yesterday. The
2008 Nov 21
0
ogg dirac granulepos in oggz tools
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 granulepos and dependency ordering, so let's leave them >>> for the next
2008 Nov 04
1
[PATCH] liboggz: Update Dirac granulepos definition
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);
2008 Nov 17
0
[Schrodinger-devel] ogg dirac granulepos in oggz tools
On Mon, Nov 17, 2008 at 11:41 AM, Ralph Giles <ralph.giles at artifex.com> wrote: > On Sun, Nov 16, 2008 at 3:22 PM, Silvia Pfeiffer > <silviapfeiffer1 at gmail.com> wrote: > >> Plus, the W3C is currently >> investigating a new ontology for video/audio metadata. This may be a >> good extension for vorbiscomment once finished. > > Ooh, can you say
2008 Nov 16
3
[Schrodinger-devel] ogg dirac granulepos in oggz tools
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
2008 Aug 16
2
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:
2008 Dec 04
3
ogg dirac granulepos in oggz tools
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,
2008 Feb 28
2
Re: Updating the Ogg mapping for Dirac
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
2010 Jan 25
2
Dirac question
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 client: http://www.opera.com/mail/
2008 Nov 13
5
ogg dirac granulepos in oggz tools
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 Feb 12
0
Header packet multiplicity
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