get_last_absgp may not work properly for chained streams

[TonalidadeHidrica]

As far as I can read from the specs, in an ogg files that has multiple chained logical streams, there is no guarantee that the absolute granule position for all streams are monotonically increasing. That is, after the first stream ends with the granule position 1000, the next stream may start at granule position -100 or something. Performing binary search on such files does not behave properly, and therefore we cannot seek to the right position.

How can we solve this problem? There are several ideas:

• Maybe we can assume that most real-word ogg files use monotonically increasing. If so, we can leave the current function as-is, with a caution written in the document. Even so, we have to modify the bisect algorithm so that it ignores the first three header packets, whose granule position is defined to be 0 by spec.
• We can provide a seeking function only within the current logical stream. Such function should first bisect for the end of the current stream (using the fact a stream must not be multiplexed), and then bisect within the range of the current stream.
  • The algorithm can be enhanced so that it supports relative seeking on chained stream. Once we detected that the seeking target is beyond the stream, we can move on to the succeeding one and perform the same operation mentioned above. This may, however, require many times of seeking and be inefficient.
• Instead of performing bisect for every seeking, we can scan the entire physical stream once beforehand (or on-demand), and then jump to the desired position. This is useful if users want to perform seeking many times. As long as reading from the source is fast enough, this does not require so much time and memory, I guess.

[est31]

The second idea is the best, I'm not so sure whether I want the third idea as this cache has unbounded size.