[haiku-development] Re: Donating codes: APE reader
- From: Stephan Assmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 31 May 2008 22:41:47 +0200
SHINTA wrote:
> Hi,
>
> > Here is a code which is the static version of APE. Thank you.
> > http://www2u.biglobe.ne.jp/~shinta/test/APEReaderDonate.zip
> > http://www2u.biglobe.ne.jp/~shinta/test/LibMonkeysAudioDonate.zip
>
> This code has two problems.
>
> One is taking long time in CAPEHeader::FindDescriptor(). 1 byte x 1
> mega times disk access seems to be slow, although this code worked well
> in ZETA.
Maybe the time is drawing near where it becomes clear that Haiku really
should have that read-ahead feature. :-)
> Another is no support for seeking. Seek code doesn't work.
I have not looked at the code yet, but maybe these comments are helpful: At
the _decoder_ level, seeking usually means to discard any "buffered
results". For example, a video decoder might still buffer some previous
frames for reference for the next frames. These should be discarded and the
decoder should assume that the next chunk data starts with a "keyframe", or
let's say with a position that is independend of any other data.
Which gets us to what the extractor needs to do. In Haiku the "Reader". The
reader needs to make sure that it only seeks to positions in the stream
that do not reference other stream data. In video streams, this is called a
keyframe. I have just learned that for newer video codecs, there is even
different types of keyframes, some positions are not truely independent of
previous data. But you can only ever seek to keyframes that are truely
independent of anything else.
In Haiku, I have implemented seeking for the AVI reader. The AVI reader
maintains a list of chunk indices which have certain flags. It will simply
iterate over the chunks of a specific stream and check the keyframe flag.
The API for the Decoder plugin could be somewhat misleading. The API allows
the decoder to adjust the seek frame. David McPaul has recently written an
email about how he handles this in the 3ivx decoder, which involved
decoding the stream from the keyframe until the seek frame without going
through the whole post processing code to reach it faster. But if you write
your Decoder to only reset itself in the Seek function and take care of
figuring out the keyframe position in the Reader, then you should be fine.
Best regards,
-Stephan
Other related posts:
