search for: davidf

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)' f...

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

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

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

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

I have a few CentOS 5.3 servers out at remote sites that connect over a satellite link (a painfully slow satellite link). There's a time period in the wee hours of the morning when the satellite provider doesn't stiff me for bandwidth, and when the link is generally idle, where I want to use rsync to back up files to my local server. I've got rsync working in in combination with

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

On 2008-11-23, Conrad Parker <conrad at metadecks.org> wrote: > 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->p...

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

Hello, Can someone give me an idea of the memory requirements for using libFLAC? I'm trying to incorporate FLAC support into a player application for the Rio Receiver (see http://rioreceiver.comms.net for details), but I'm having trouble because FLAC__stream_decoder_new() is attempting to allocate 2099828 bytes for an instance of the FLAC__StreamDecoderPrivate struct. Is this accurate,

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

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

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);

On Tue, Nov 4, 2008 at 12:56 AM, David Flynn <davidf+nntp at woaf.net> wrote: > Quite a while ago, the specification was modified to change the > way the nondefault scan format was signalled; this patch fixes that. Thanks for the patch. I've tried to fix things as discussed on irc. Please review r3762. Index: /liboggz/trunk/src/libogg...

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

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

--- Dave Flowerday <davidf@pier13.com> wrote: > Hello, > Can someone give me an idea of the memory requirements for using > libFLAC? > I'm trying to incorporate FLAC support into a player application for > the > Rio Receiver (see http://rioreceiver.comms.net for details), but I'm > having tr...

Hey guys, I've done a ton of googling, searching and asking in the forums, etc, and I haven't found a way to do this... :) I'm trying to find a way of having some type of screen saver at the login screen so that if I leave a machine not logged into, it won't burn-in the screen. Does anyone know of a way to achieve this? In specific, I'd love to have it simply blank the

...better. GPH+GPL=frame works for theora, but doesn't do any better with naive seeking than 'find this numerical granulepos' and doesn't simplify frame-accurate seeking if you relax the one-page-per-packet rule, which I think we must. On Wed, Aug 13, 2008 at 1:08 PM, David Flynn <davidf+nntp at woaf.net> wrote: > Defacto rules of ogg (I've not found these actually written down anywhere): No, we've not really worked out these parts of the spec. Thanks for helping! > - Seeking is difficult: > - Want to seek to frame N > - GPH+L is non-unique (don...