Folks, the packets I want to place in an ogg stream are concatenations of two hunks of memory. Rather than memcopy() them into one then pass them to libogg, I patched framing.c to accept iovecs. The unified diff is 80 lines, minus the OS-specific stuff for defining struct ogg_iovec_t - pretty trivial. Is there any interest in it? Or is libogg frozen while all efforts are concentrated on libogg2? I had a look at libogg2 and that will not be a simple patch, so rather than attempt one I'll simply enter a feature-plea: please consider equipping libogg2 with one of these: ogg_stream_iovecin(ogg_stream_state *os, ogg_iovec_t *iov, int count, long e_o_s, ogg_int64_t granulepos) Thanks.
On 1/12/07, Ard <andrew.donkin.ogg@gmail.com> wrote:> Folks, the packets I want to place in an ogg stream are concatenations > of two hunks of memory. Rather than memcopy() them into one then pass > them to libogg, I patched framing.c to accept iovecs. > > The unified diff is 80 lines, minus the OS-specific stuff for defining > struct ogg_iovec_t - pretty trivial. > > Is there any interest in it? Or is libogg frozen while all efforts are > concentrated on libogg2?If it's purely a binary-compatible API addition, we'd certainly consider it - please send in your patch. Nobody is actively developing on either libogg or libogg2, but if there are sufficiently useful contributions we'd do a new release. Can we ask what you're doing with ogg, specifically? Mike
On 1/11/07, Ard <andrew.donkin.ogg@gmail.com> wrote:> Folks, the packets I want to place in an ogg stream are concatenations > of two hunks of memory. Rather than memcopy() them into one then pass > them to libogg, I patched framing.c to accept iovecs. > > The unified diff is 80 lines, minus the OS-specific stuff for defining > struct ogg_iovec_t - pretty trivial. > > Is there any interest in it? Or is libogg frozen while all efforts are > concentrated on libogg2? > > I had a look at libogg2 and that will not be a simple patch, so rather > than attempt one I'll simply enter a feature-plea: please consider > equipping libogg2 with one of these: > > ogg_stream_iovecin(ogg_stream_state *os, > ogg_iovec_t *iov, int count, > long e_o_s, ogg_int64_t granulepos)This suggestion seems perfectly sensible to me. libogg1 isn't particularly frozen, it was just considered 'finished' is all. Monty