#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
Keywords: | Blocked By:
Blocking: | Has a Patch: 0
Platform: All |
----------------------------+------------------------------
See attached sample. Here's an outline of what it does:
Steps:
- ReadFrames()
- dump bytes
- '''SeekToTime( time 0 )''' (SeekToFrame() also triggers the bug)
- ReadFrames()
- dump bytes : they are badly corrupted ! (not at all like those returned
by a "fresh" BMediaTrack)
It seems the 'corruption' is not quite random, the buffer seems to be
filled with average values (old buffer + new buffer / 2). For instance if
you read only one buffer's worth of data (instead of 22 as in my sample)
and the data is 0x0 through and through, doing a Seek and then
ReadFrames() again will still return a buffer filled with 0x0's as it
should. But if you went farther along in the audio file and your last read
buffer had high volume samples, seeking back to the (silent) beginning of
the file will no longer yield 0x0s but medium'ish samples instead.
Workaround 1 is to discard the BMediaFile object and re-instantiate it
before seeking (too expensive).
Workaround 2 is to keep the BMediaFile and BMediaTrack, but throw away the
contents returned by the first 2 ReadFrames() calls as it seems they are
the only ones "polluted".... Not a great solution, would love to see
ReadFrames() be fixed to start with :-)
--
Ticket URL: <https://dev.haiku-os.org/ticket/12436>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.
