it should be more like the scheduling latency, if anything.
* fBufferMap contained uint32 values, instead of simply the
BBuffer pointers.
* fBufferMap was initialized in a very complicated way,
simply use the BBuffer pointer returned from
fBuffers->AddBuffer().
* Removed methods which were only implemented because of a
Codewarrior compiler bug.
* Renamed fTargetBufferIndex to fLastBufferIndex, since it's
the index of the last used BBuffer from fBufferMap, which
needs to be recycled when the next buffer is received.
* SetOutputBuffersFor() never worked (making the producer
use the consumer buffer group), since it was passed the
never initialized fDestination. Use fIn.destination.
* But using our own buffer group did not yet work, since
apparently the BBuffer pointers cannot be compared like
the code did (no idea if it ever worked on BeOS).
Compare the ID()s instead, which makes it finally work to
save an unnecessary memcpy(). Interestingly, one can
call Recycle() on the "wrong" BBuffer pointer and buffers
still get recycled correctly.
* Refactored methods _UnsetTargetBuffer() and _HandleBuffer().
* Maintain the performance start time, may come in handy later.
* Changed code that checks lateness or earliness of buffers.
In case a buffer is early, simply wait.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38661 a95241bf-73f2-0310-859d-f6bbb57e9c96
data, so we should prevent showing a current
peak of 0. Fixes the periodic 0 peaks.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38660 a95241bf-73f2-0310-859d-f6bbb57e9c96
it can be any of these values, hope the priority is right.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38659 a95241bf-73f2-0310-859d-f6bbb57e9c96
frame rate (perhaps it changed in 0.6?). This fixes
playback of several MP4 clips I have for testing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38658 a95241bf-73f2-0310-859d-f6bbb57e9c96
not the current real time. If I understand things
correctly, using the mechanism to send a MessageEvent
is just there to invoke SetPerformanceTime() within
the PlaybackManager BLooper (I could be mistaken).
Need to check whether this fixes a drift in audio
and video I am often observing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38655 a95241bf-73f2-0310-859d-f6bbb57e9c96
the counters, so it's not the average for the entire
decoding time, but for the last five frames. This gives
a more accurate picture of what's going on.
* Added NOTE about possibly removing the SWS version of the
colorspace conversion code unless it's used for otherwise
unsupported conversions. David's code is about 40% faster
in my tests (nice job!).
* Free the sws context in NegotiateVideoFormat, if necessary.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38651 a95241bf-73f2-0310-859d-f6bbb57e9c96
was not big enough. Axel, perhaps another solution is
better? Would you prefer the chunk cache to fall-back
to regular memory and keep track of allocation type?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38649 a95241bf-73f2-0310-859d-f6bbb57e9c96
of support for these codecs and demuxer in the FFmpeg plugin. The
ogg test streams I downloaded play fine now. For example, Big Buck Bunny
would play without video before and ogg files natively encoded with the
FFmpeg plugin wouldn't play at all. Since the removed plugins were not
maintained and were based on external libs themselves, I didn't see the
point in keeping them.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38646 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Enabled ogg muxer in MuxerTable.
ogg/vorbis creation successfully tested with MediaConverter.
ogg/theora needs more testing, it seems to work, but I need
to switch from the other vorbis/theora/ogg plugins to the
FFmpeg built-in support, otherwise the current theora stream
is not supported by the old plugin.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38641 a95241bf-73f2-0310-859d-f6bbb57e9c96
in order not to clash with the old libtheora in the theora plugin.
x86 CPU optimizations are only compiled for GCC4.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38640 a95241bf-73f2-0310-859d-f6bbb57e9c96
in order not to clash with the old libvorbis in the vorbis plugin. I plan to remove
that one after I've done more testing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38639 a95241bf-73f2-0310-859d-f6bbb57e9c96
float_to_int16_interleave_sse, since it crashes for reasons
I would have no clue about. Fixes a few duplicated tickets,
which I'll have to sort out later.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38636 a95241bf-73f2-0310-859d-f6bbb57e9c96
* avoid trying to overwrite values of a constant structure when
updating the numeric locale data values used by glibc
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38623 a95241bf-73f2-0310-859d-f6bbb57e9c96
