Re: ov_pcm_seek to sample zero of Theora/Vorbis file hangs
[email protected] Wed, 11 Jun 2014 15:42:21 -0700
| Newsgroups | gmane.comp.multimedia.ogg.vorbis.devel |
|---|---|
| Message-ID | <CACrD=+-Hc5+_ee=TZ4+TWdLHEE+htWKV-+AtMV5wb4a6q4cw2g@mail.gmail.com> |
Patch committed in r19159, description of Trac #1486 updated. Not closed yet. Monty On Wed, Jun 11, 2014 at 12:12 PM, <[email protected]> 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 <[email protected]> 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 >> [email protected] 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 <[email protected]> wrote: >>>> On Fri, 23 May 2014 23:51:58 +0100 >>>> Ian Nartowicz <[email protected]> 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 >>>> [email protected] >>>> http://lists.xiph.org/mailman/listinfo/vorbis-dev >>