Vorbis - May 2015 - How do I seek to seek to specific samples using libvorbis?

Thanks.

 

If decoding from the last packet on the previous page works, I may have to
do that. But I was hoping to avoid it. Yes, I may be seeking a lot. A packet
spanning multiple pages shouldn't be a problem for me, because I'm only
adding index points that represent the beginning of a packet. But does this
actually happen for Vorbis? (Aside from large header packets) The large
blocks I've encountered seem to be 1024 samples per channel. Even with
8-channel audio, uncompressed floating-point PCM sound, such a packet would
only take up 129 segments on the segment table.

 

Madison

 

 

From: Jordan Verner [mailto:jv_erner at hotmail.com] 

Sent: Tuesday, May 19, 2015 12:20 PM

To: Madison Link

Subject: RE: [Vorbis] How do I seek to seek to specific samples using
libvorbis?

 

What I did was performed a binary search in my ogg vorbis file, in order to
find the page proceeding the page containing the desired sample (you can
determine this using the granule position). Next, I used ogg_page_packets()
to determine how many packets complete on that page, skip to the final
packet by calling ogg_stream_packetout N times and just ignoring the result.
Then decode the page's final packet. This should mean that the next sample
you decode will actually be the one the granule position says it is. Then
you have to calculate an offset between the sample you're at and the one you
want, decode that many and discard them. In practice this seems to work but
leaves a lot to be desired. You could be decoding up to an entire page of
audio (slow if you seek a lot), and there's an off chance that a complex and
rare case involving a packet spanning three or more pages could still throw
you off. I think it could be possible to do it with only decoding two extra
packets if you can calculate where you'll end up based on blocksize values
and window overlapping rules, but it's not well explained. The spec leaves a
lot to be desired.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/vorbis/attachments/20150519/ece22ee3/attachment.htm

This thread reminded me of Ralph's LCA presentation entitled "Seeking
is
Hard". <http://xiph.org/~giles/>

Not sure if it contains anything you don't already know, but worth a
mention.

- Josh

On 2015-5-20 06:55 , Madison Link wrote:
> Thanks.
> 
>  
> 
> If decoding from the last packet on the previous page works, I may have
> to do that. But I was hoping to avoid it. Yes, I may be seeking a lot. A
> packet spanning multiple pages shouldn't be a problem for me, because
> I'm only adding index points that represent the beginning of a packet.
> But does this actually happen for Vorbis? (Aside from large header
> packets) The large blocks I've encountered seem to be 1024 samples per
> channel. Even with 8-channel audio, uncompressed floating-point PCM
> sound, such a packet would only take up 129 segments on the segment table.
> 
>  
> 
> Madison
> 
>  
> 
>  
> 
> From: Jordan Verner [mailto:jv_erner at hotmail.com]
> 
> Sent: Tuesday, May 19, 2015 12:20 PM
> 
> To: Madison Link
> 
> Subject: RE: [Vorbis] How do I seek to seek to specific samples using
> libvorbis?
> 
>  
> 
> What I did was performed a binary search in my ogg vorbis file, in order
> to find the page proceeding the page containing the desired sample (you
> can determine this using the granule position). Next, I used
> ogg_page_packets() to determine how many packets complete on that page,
> skip to the final packet by calling ogg_stream_packetout N times and
> just ignoring the result. Then decode the page's final packet. This
> should mean that the next sample you decode will actually be the one the
> granule position says it is. Then you have to calculate an offset
> between the sample you're at and the one you want, decode that many and
> discard them. In practice this seems to work but leaves a lot to be
> desired. You could be decoding up to an entire page of audio (slow if
> you seek a lot), and there's an off chance that a complex and rare case
> involving a packet spanning three or more pages could still throw you
> off. I think it could be possible to do it with only decoding two extra
> packets if you can calculate where you'll end up based on blocksize
> values and window overlapping rules, but it's not well explained. The
> spec leaves a lot to be desired.

On Wed, May 20, 2015 at 10:45:25AM +1000, Joshua Root
wrote:
> This thread reminded me of Ralph's LCA presentation entitled
"Seeking is
> Hard". <http://xiph.org/~giles/>
> 
> Not sure if it contains anything you don't already know, but worth a
> mention.
 Also worth mentioning that there's currently a USD5000 bounty on seek
support
for the stb lib, but perhaps the hread-starter is already aware.

 Notes from a previous attempt:
 http://nothings.org/stb_vorbis/ogg_seek.txt

 Issue:
 https://github.com/nothings/stb/issues/117