frame on-screen, instead of going black until catching up.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38672 a95241bf-73f2-0310-859d-f6bbb57e9c96
for single frame stepping instead of winding. One frame without
shift-modifier, five frames with shift held down.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38671 a95241bf-73f2-0310-859d-f6bbb57e9c96
video generation. This allows step back frame-wise even though
it means the video has to seeked back far and re-generated more
than five frames ahead to reach the seek frame.
* Don't print dropped frames in the producer when the video
is paused.
* Don't lock the PlaybackManager to report dropped frames,
report it later when the manager had to be locked anyway.
* Removed a whole bunch of methods that were only implemened
because of that old BeOS PPC compiler bug.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38670 a95241bf-73f2-0310-859d-f6bbb57e9c96
on the current play back mode. I.e. paused or stopped
playback get's B_OFFLINE run-mode, which makes sure the
Consumer does not drop frames when they are too late.
When single stepping frames backwards, the producer may
have needed a lot of time to generate a frame and it may
arrive late, which is no problem when the video is paused.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38667 a95241bf-73f2-0310-859d-f6bbb57e9c96
Added BurnItNow, both a gcc2 and gcc4 build.
Added Bazaar, both a gcc2 and gcc4 build.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38665 a95241bf-73f2-0310-859d-f6bbb57e9c96
Seems to work around a problem in the system mixer. When it
happens once that the AudioProducer does not send a buffer,
then it can eventually lead to a drop into the debugger
from BBuffer::SetHeader(), which to me looks like the BMediaEventLooper
thread of the mixer still runs when the System Mixer has been
shut down, which itself is yet another problem. I shall
investigate, but for the time being, one should enjoy a more
stable media_addon_server life-time.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38664 a95241bf-73f2-0310-859d-f6bbb57e9c96
compute the latency from the buffer count. It should be
the duration of in-flight buffers (i.e. number of buffers
minus the one currently showing).
* Compute the wakeUp time based on the buffer latency used
above.
* Make the "wasCached" mechanism work again, i.e. don't send
the buffer to the consumer if the contents did not change.
This removes the need to cache frames in the ProxyVideoSupplier
and thus one more memcpy() (5ms on my Q6600 for full-HD content).
* Remove the weird forceSendingBuffer override and the setting
of the header starttime to 0. Now seeking clips works also
when the playback is paused.
All in all, playback is more efficient now, and the chances of
dropping frames are much less. Something is still fishy, though,
since VLC, even though seemingly using slightly more CPU, drops
frames more seldomly than MediaPlayer. Audio/Video sync seems to
be better, though, since the VideoProducer is using a more accurate
latency now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38662 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
