[Vorbis-dev] ov_pcm_seek to sample zero of Theora/Vorbis file hangs

[xiphmont at xiph.org]

I saw the bug was reopened and asssumed it was related, but I wanted
to verify the chain of events before deciding two possibly different
problems were the same thing and getting confused.

The bisection as written was for old unmultiplexed files and 'failed'
intentionally in the case when the seek was at the first pcm offset.
In multiplexed files, the fail is not [necessarily] happening at the
very beginning, and so violates the original design invariant and the
logic further unravels from that point on.  It should never be getting
as far as trying to seek backwards after the bisection.

In any case, there's a bug and a newly exposed inefficiency here.  I
need to fix both, which is easy, and test both, which may take a bit
longer.  Opusfile does handle this case properly by adjusting the
bisection target for the special case of 'the very beginning'.

Monty





On Wed, Jun 11, 2014 at 6:18 AM, Ian Nartowicz <flac at nartowicz.co.uk> wrote:
> I found this old Trac bug and re-opened it:
> https://trac.xiph.org/ticket/1486
>
> It includes a potential one-line fix that works for me with my test cases, but I
> suspect needs a little more work.
>
> --ian
>
>  On Tue, 10 Jun 2014 15:54:37 -0700
> xiphmont at xiph.org wrote:
>
>>Sorry to take a few days to respond to this.  Reproduced here, looking
>>at it now.  BTW, thank you for the extensive pre-analysis, that should
>>make things a ton easier to fix.  More in a bit...
>>
>>Monty
>>
>>On Sat, Jun 7, 2014 at 2:52 PM, Ian Nartowicz <flac at nartowicz.co.uk> wrote:
>>> On Fri, 23 May 2014 23:51:58 +0100
>>> Ian Nartowicz <flac at nartowicz.co.uk> wrote:
>>>
>>>>Hi all,
>>>>
>>>>I'm having a little trouble with a Vorbis decoder hanging (actually hard
>>>>looping the CPU) when I call ov_pcm_seek(&vorbis_file, 0) on a multiplexed
>>>>theora/vorbis file.  It appears to be the vorbisfile library that has the
>>>>problem.  The call to ov_pcm_seek never returns.
>>>>
>>>>Seeking in non-multiplexed, including chained, files is OK.  Seeking to other
>>>>values, including sample 1, works OK.  Has anyone else seen this?
>>>>
>>>>I have tested against Big Buck Bunny:
>>>>http://www.bigbuckbunny.org/index.php/download/
>>>>
>>>>and plane.ogg from Wikipedia:
>>>>https://en.wikipedia.org/wiki/File:I-15bis.ogg
>>>>
>>>>--ian
>>>
>>> So, to partially answer my own question.  This goes into an infinite loop in
>>> _get_prev_page in vorbisfile.c, with begin=0 and end=0.  Perhaps this
>>> function should never be called since it clearly can't handle this situation.
>>>
>>> --ian
>>>
>>> Here is the whole sequence (op_pcm_seek_page):
>>> 1. Bisect to find the page with a PCM less than or equal to the seek offset
>>> (zero).
>>> 2. Start at PCM zero and exit as soon as the first page from the Vorbis
>>> stream (the second page in this case) is read.
>>> 3. Because there was never actually any bisection, the raw offset is never
>>> set to point at a Vorbis page, and is still zero.  It would normally point
>>> exactly at a page in the Vorbis stream, a page containing the desired PCM.
>>> 4. Seek to the raw offset (zero) and blindly dump in the first page we find,
>>> which is actually a Theora page (this fails, but the error is not detected).
>>> 5. The stream is empty so packetpeek returns zero and the loop assumes that
>>> it needs to get the previous page until it finds the start of the packet.
>>> 6. Of course it will never find the start of the packet because it is already
>>> at the start of the file and before the first Vorbis packet.  Loop
>>> forever ....
>>>
>>> So that's what is broken, but I have no clue how to fix it.  A naive fix
>>> might be to not assume the first page is from the correct stream and keep
>>> reading, but it seems like it would be better just to make sure the raw seek
>>> position is correct beforehand.
>>>
>>> --ian
>>> _______________________________________________
>>> Vorbis-dev mailing list
>>> Vorbis-dev at xiph.org
>>> http://lists.xiph.org/mailman/listinfo/vorbis-dev
>