[Fwd: libvorbis without encapulsation]

--=-YhhlQzNguV2umN2IZghq
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

.... although I see now that the address of vorbis_block.buffer
is  0x647c80, which at least fits between  0x647b40 and 0x647d90 in the
vorbis_block_internal packetblob array, which is occupied by the "stack
address" for the aformentioned oggpack_buffer, and whose addresses
otherwise are pretty contiguous.

Maybe that has some significance?
--=-YhhlQzNguV2umN2IZghq
Content-Disposition: inline
Content-Description: Forwarded message - [Vorbis-dev] libvorbis without
 encapulsation
Content-Type: message/rfc822

Return-Path: <[email protected]>
Delivered-To: lash
Return-Path: <[email protected]>
X-Envelope-From: [email protected]
X-Envelope-To: <[email protected]>
X-Original-To: [email protected]
Delivered-To: [email protected]
X-Virus-Scanned: amavisd-new at osuosl.org
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; q=dns/txt;
 d=holbrook.no; [email protected]; s=mailjet;
 h=domainkey-signature:message-id:mime-version:from:to:subject:date:list-unsubscribe:x-csa-complaints:
 x-mj-mid:content-type:content-transfer-encoding;
 bh=/n4hb8kZ8FZ9w29ztqfAo/gI+3g=;
 b=XL6rKfX5vosKYDcLjX3HjUQEEPDL4NZA/z/nh++JVCjvxMDyw3t9LkVsw
 qbku+LFmUdMRapKEW0UzVL/a1mxOdhCs0Rp+H7cL31o27hgEVqsX6XOIgV1z
 fKSuzsnJ/ebhPqglQkVeE5HhN3p7MO4EOFWgZm1TR1fnvYRwMnKaNs=
DomainKey-Signature: a=rsa-sha1; c=simple; q=dns; d=holbrook.no; s=mailjet;
 h=message-id:mime-version:from:to:subject:date:list-unsubscribe:x-csa-complaints:
 x-mj-mid:content-type:content-transfer-encoding;
 b=d1lkh3nWMMRiB0gB7LZ/6A6u8eykBdVnwVPLexxSyP8CXASDR5OsHStM6
 z7f9Sxp2+WjacZO6COqxCjy4zlQGwDSEagXjfuFkaugwfAZvXunLZa0vbmZL
 qi9rsQ/EyjU2OthOlLQScLePEuiNa3ckw11RvruJiWllnFsVmJTq8g=
Message-Id: <35f734fd.AEMAHj0aUHkAAAAAAAAAAGpRNKYAARpaZXMAAAAAAAdjoABYmDX5@mailjet.com>
Mime-Version: 1.0
From: Miscellaneous <[email protected]>
To: [email protected]
Date: Mon, 06 Feb 2017 09:37:29 +0100
X-CSA-Complaints: [email protected]
X-MJ-Mid:  AEMAHj0aUHkAAAAAAAAAAGpRNKYAARpaZXMAAAAAAAdjoABYmDX5fkv8JDy2RPqC0zqHogVTDAAHCvo
Subject: [Vorbis-dev] libvorbis without encapulsation
X-BeenThere: [email protected]
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: audio codec development <vorbis-dev.xiph.org>
List-Unsubscribe: <http://lists.xiph.org/mailman/options/vorbis-dev>,
 <mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lists.xiph.org/pipermail/vorbis-dev/>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.xiph.org/mailman/listinfo/vorbis-dev>,
 <mailto:[email protected]?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Errors-To: [email protected]
Sender: "Vorbis-dev" <[email protected]>
X-Spam-Score: (-6.599) BAYES_00,RCVD_IN_DNSWL_MED
Content-Transfer-Encoding: 8bit

Using libvorbis (1.3.5) I wish to extract the raw vorbis packets. 

I've built some simple code on the excellent libvorbis API overview on
the xiph.org site, but the example relies on the ogg_packet struct for
final output and input to decoder, and shows now examples on how to do
without it.

Taking a look at the vorbis_bitstream_flush() function, which in the
overview is the last step before output, it seems that there is an
oggpack_buffer in an array of buffers internal to vorbis_block:

(*vorbis_block.internal)(vorbis_block.internal)->packetblob[PACKETBLOBS 
/ 2]

(PACKETBLOBS = 15, the macro is not commented, so don't know what this
is).

This is the output of a encoder pass from gdb:

(gdb) p *vbi
$3 = {pcmdelay = 0x647140, ampmax = -58.0271301, blocktype = 0,
packetblob = {0x6473c0, 0x647500, 0x647640, 0x647780, 0x6478c0, 
    0x647a00, 0x647b40, 0x7fffffffdeb8, 0x647d90, 0x647ed0, 0x648010,
0x648150, 0x648290, 0x6483d0, 0x648510}}

The stack address is the "oggpack_buffer index" in question. I can't
find this address anywhere else (on the surface):

vorbis_block:
(gdb) p vblk 
$4 = {pcm = 0x643770, opb = {endbyte = 117, endbit = 0, 
    buffer = 0x647c80
"\354*\020\003QQi~\352\306\061\356TޮSD\271\235g\257\267է\273_/;\255\231
\232Xk^;2-
\352\352X{\275\246\365\f\a\255W6\371f_=a~\302\337\365\343׆?Jj\210\262\3
71\245\367u\266z\257\325\334T\355\365\200\327T\346\a%\255r\313\361PF\23
1\016\311\323\353\032U\177\247W9\344ĴU\262\tc\321\360\234)ǔ_z)", ptr =
0x647cf5 "", storage = 256}, lW = 0, W = 0, nW = 0, pcmend = 512, mode
= 0, 
  eofflag = 0, granulepos = 0, sequence = 3, vd = 0x7fffffffde20,
localstore = 0x64a380, localtop = 64, localalloc = 64, 
  totaluse = 7376, reap = 0x64a360, glue_bits = 0, time_bits = 0,
floor_bits = 0, res_bits = 0, internal = 0x647330}

vorbis_dsp_state:
(gdb) p vdsps
$10 = {analysisp = 1, vi = 0x7fffffffdde0, pcm = 0x642750, pcmret =
0x642770, pcm_storage = 221012, pcm_current = 55376, 
  pcm_returned = 0, preextrapolate = 1, eofflag = 0, lW = 0, W = 0, nW
= 0, centerW = 512, granulepos = 256, sequence = 4, 
  glue_bits = 0, time_bits = 0, floor_bits = 0, res_bits = 0,
backend_state = 0x608790}

=====

oggpack_buffer comes from ogg/ogg.h, so I guess it may add some things
not native to "pure" vorbis.

Am I to understand that I am dependent on the ogg library to get data
in and out? And if not, where can I get the data along with the minimal
metadata I need? (bytes, granulepos?)


_______________________________________________
Vorbis-dev mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/vorbis-dev

--=-YhhlQzNguV2umN2IZghq
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVm9yYmlzLWRl
diBtYWlsaW5nIGxpc3QKVm9yYmlzLWRldkB4aXBoLm9yZwpodHRwOi8vbGlzdHMueGlwaC5vcmcv
bWFpbG1hbi9saXN0aW5mby92b3JiaXMtZGV2Cg==

--=-YhhlQzNguV2umN2IZghq--