So, I abandoned the hope of using the ogg python bindings to do pure ogg container encoding. I started looking at the libogg in the hopes of retooling the bindings to follow a better object model and it actually looks like the problem is down in libogg, not the bindings. Am I crazy or does libogg rely on libvorbis to return ogg_packets, and that there are no functions that will build an ogg_packet for you from your own data like an array of bytes? It looks like API users are required to fill in all the meta fields of the ogg_packet themselves? Is this correct? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/vorbis-dev/attachments/20060605/f5093ff6/attachment.html
On Mon, Jun 05, 2006 at 09:34:43PM -0400, Stephen Whiters-Ridley wrote:> Am I crazy or does libogg > rely on libvorbis to return ogg_packets, and that there are no functions > that will build an ogg_packet for you from > your own data like an array of bytes? It looks like API users are required > to fill in all the meta > fields of the ogg_packet themselves? Is this correct?Yes, you have to fill in the metadata yourself, and a pointer to the packet body data to be framed. I'm confused as to how else you were expecting to do it? More specifically, you fill out the (ogg_packet)this.packet field with a pointer to your data array and then ogg_stream_packetin() will memcpy that buffer into internal storage (in libogg anyway, libogg2 allows for submitting a release callback.) The Vorbis and Theora reference encoders do return (or rather fill out) an ogg_packet structure for you, so it is very convenient to submit this to libogg. Of course you'll have to do this yourself if you're getting the data from somewhere else. Hope that helps? -r
Thanks for responding, So yea I was mostly getting hung up on the context switching between python and C. I see now in C how the developer needs the flexibility to packetize as he sees fit otherwise it defeats the purpose of exposing it to people writing codecs! I had to go back and read the specification, it makes more sense now...thanks for not completely flaming me. :-) On 6/5/06, Daniel Holth <dholth@fastmail.fm> wrote:> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Stephen Whiters-Ridley wrote: > > > So, I abandoned the hope of using the ogg python bindings to do > > pure ogg container encoding. I started looking at the libogg in the > > hopes of retooling the bindings to follow a better object model and > > it actually looks like the problem is down in libogg, not the > > bindings. Am I crazy or does libogg rely on libvorbis to return > > ogg_packets, and that there are no functions that will build an > > ogg_packet for you from your own data like an array of bytes? It > > looks like API users are required to fill in all the meta fields of > > the ogg_packet themselves? Is this correct? > > Yes, the low-level libraries are all very messy with an unclear > separation of who owns which object. Structures invalidate when you > call functions (that do not warn you that this is happenning). All > very confusing. When I was looking at it I concluded that it needed a > higher-level API to be memory safe (to not allow Python programmers to > segfault). My boost.python based oggpy is not safe, but this is an > example of putting non-vorbis into an ogg stream: > > import oggpy > import sys > > granule = 0 > > os = oggpy.stream(0x00FF00FF) > page = oggpy.page() > > pack = oggpy.userpacket("OGGText", granule, True, False) > os.packetin(pack) > > os.flush(page) > sys.stdout.write(page.header()) > sys.stdout.write(page.body()) > > for data in sys.stdin.readlines(): > if data[0] == chr(12): > while(os.flush(page) != 0): > sys.stdout.write(page.header()) > sys.stdout.write(page.body()) > granule += 1 > pack = oggpy.userpacket(data, granule, False, False) > os.packetin(pack) > > pack = oggpy.userpacket("", granule, False, True) > os.packetin(pack) > os.pageout(page) > sys.stdout.write(page.header()) > sys.stdout.write(page.body()) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (Darwin) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFEhOaAVh4W2pVfoMsRApcJAKC1ugOh/R6g93jbMJrZObtZ49VPWACgtC1B > XUdRpnVF/sM8IvWOYWxoQ+4> =ss9O > -----END PGP SIGNATURE----- > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/vorbis-dev/attachments/20060606/d1d09f76/attachment.html
Hi Stephen, On Mon, Jun 05, 2006 at 09:34:43PM -0400, Stephen Whiters-Ridley wrote:> So, I abandoned the hope of using the ogg python bindings to do pure ogg > container encoding. > I started looking at the libogg in the hopes of retooling the bindings to > follow a better object model> and it actually looks like the problem is down in libogg, not the bindings. > Am I crazy or does libogg rely on libvorbis to return ogg_packets, > and that there are no functions that will build an ogg_packet for you from > your own data like an array of bytes?You're not crazy, libogg requires applications using it to construct ogg_packet structures. Fortunately for libogg (not libogg2), this is fairly simple, though libogg does not offer any helper functions for it. The building of libogg does not depend on libvorbis, and using libogg to do other things with ogg does not require libvorbis.> It looks like API users are required to fill in all the meta > fields of the ogg_packet themselves? Is this correct?yes. The fields of the ogg_packet structure (particularly the granulepos) are very dependent on the codec. btw. if you're writing python bindings, perhaps have a look at binding liboggz: http://www.annodex.net/software/liboggz/index.html It wraps libogg and provides a somewhat clearer API (IMHO ;-) It can also work out things like the bos, eos and packetno flags for you automatically, though you still need to fill in the packet data and granulepos; and it ensures that you don't insert invalid packets. cheers, Conrad.