[Vorbis-dev] ov_pcm_seek to sample zero of Theora/Vorbis file hangs
xiphmont at xiph.org
xiphmont at xiph.org
Wed Jun 11 15:42:21 PDT 2014
Patch committed in r19159, description of Trac #1486 updated. Not closed yet.
Monty
On Wed, Jun 11, 2014 at 12:12 PM, <xiphmont at xiph.org> wrote:
> 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
>>
More information about the Vorbis-dev
mailing list