#12436: BMediaTrack()::ReadFrames() polluted after Seeking
------------------------------+----------------------------
Reporter: ttcoder | Owner: Barrett
Type: bug | Status: new
Priority: high | Milestone: R1/beta1
Component: Kits/Media Kit | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
------------------------------+----------------------------
Comment (by ttcoder):
Seems I selected the wrong component indeed, it should be the mp3 codec
instead. Details:
- first tried the APE file
[http://samples.mplayerhq.hu/A-codecs/lossless/luckynight.ape here] but
playback is completely silent. Haiku does have a '/system/add-
ons/media/plugins/ape_reader' add-on but I'm not sure it's used, seems
ffmpeg is used instead for reading the ape audio:
{{{
Compiler did not align stack variables. Libavcodec has been miscompiled
and may be very slow or crash. This is not a bug in libavcodec,
but in the compiler. You may try recompiling using gcc >= 4.2.
Do not report crashes to FFmpeg developers.
########### audio decode error, fTempPacket.size 0, fChunkBuffer data
offset 0
...
BMediaTrack::ReadFrames: decoder returned error 0x80004007 (Last buffer)
...
BMediaTrack::ReadFrames: decoder returned error 0x80000000 (Out of memory)
...
}}}
- then I tried luckynight.flac and it seems Seek'ing works normally there.
- then I tried luckynight.wav and it also seems to work normally
- if going back to an mp3 however, the bug is back.
Maybe the mpeg layer 3 algorithm uses some sort of "rolling average" or
psycho-accoustic machine state that ought to be reset (but is currently
not) when Seek'ing, or something like that ?
--
Ticket URL: <https://dev.haiku-os.org/ticket/12436#comment:3>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.
