mediaplayer/consumer: Fix 64-bit debug tracing

MediaPlayer: some 64 bit fixes

MediaPlayer: VideoConsumer now prints bounds when buffer can't be allocated.

For the time being, don't enable a shared BBufferGroup
in overlay mode. Added TODO, since it should be fixed
eventually. There seems to be a problem with mapping
the BBitmap area into a BBuffer (video stays black).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38834 a95241bf-73f2-0310-859d-f6bbb57e9c96

Propagate the error from CreateBuffers() in Connected().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38814 a95241bf-73f2-0310-859d-f6bbb57e9c96

Code simplification and a commont on why fOurBuffers is
maintained as member variable.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38668 a95241bf-73f2-0310-859d-f6bbb57e9c96

* fMyLatency (stupid name) had an arbitrary bogus value,
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

Have MediaPlayer supports files with unknown duration:
* Controller: accept streams with unknown duration.
* PlaybackManager: trusts the current frame start and end when frameCount not positive. Also don't stop playing when fStopPlayingFrame is zero.
* MediaTrackAudioSupplier: only fills with silent when the frame count is not zero.
* added some traces.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31569 a95241bf-73f2-0310-859d-f6bbb57e9c96

Improved error logging.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31476 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fixed CID 1297: the buffList array was never deleted.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27432 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Move the color_space_to_string() function into it's own file.
* On BeOS "bitmaps_support_space()" returns false for YCbCr color spaces. :-(
* Refactor the code which sets up the decoded format in the MediaTrack-
VideoSupplier to always start with a clean format for multiple calls to
BMediaTrack::DecodedFormat().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25824 a95241bf-73f2-0310-859d-f6bbb57e9c96

Do not reference bitmap color spaces directly anymore, but use
bitmaps_support_space() interface kit function. First try to
use overlays, if that fails, try again without overlays. The
NodeManager makes sure to fall back to B_RGB32 if the given
mode is not supported for drawing bitmaps in by BViews. Thanks,
Axel, for the suggestion!


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25764 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Support codecs that don't support B_YCbCrXXX color spaces.
* Leave the codec a chance to advertise the best output color space,
try B_YCbCr422 as the most widely supported format in case the codec
does not advertise.
* Support two more overlay colorspace modes in the video consumer.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25731 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved a bunch of non-primary interface classes into a new subfolder
"interface"

* Complete reimplementation of the playback engine using Media Nodes:
- Seeking video files does not appear to lockup the playback anymore, but
works on a frame accurate level even for keyframe based streams. There is
currently a problem with certain container formats, the audio track reports
a "Device Seek Error" in certain conditions. In that case audio goes silent,
and can be restarted by going back to the beginnings of the stream.
- Video overlays are now supported.
- It would be possible to connect the output of the MediaPlayer to other
applications or dormant media nodes.

* Known regressions:
- The volume slider has currently no effect anymore.
- Switching the audio track during playback has a known race condition and
can crash the player.
- The new engine is not as "light weight" as the old one. I tagged the
previous implementation in tags/components/mediaplayer-engine-v1. It does
not seem to have any noticable effect though.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25725 a95241bf-73f2-0310-859d-f6bbb57e9c96

MediaPlayer: some 64 bit fixes

MediaPlayer: VideoConsumer now prints bounds when buffer can't be allocated.

For the time being, don't enable a shared BBufferGroup
in overlay mode. Added TODO, since it should be fixed
eventually. There seems to be a problem with mapping
the BBitmap area into a BBuffer (video stays black).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38834 a95241bf-73f2-0310-859d-f6bbb57e9c96

Propagate the error from CreateBuffers() in Connected().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38814 a95241bf-73f2-0310-859d-f6bbb57e9c96

Code simplification and a commont on why fOurBuffers is
maintained as member variable.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38668 a95241bf-73f2-0310-859d-f6bbb57e9c96

* fMyLatency (stupid name) had an arbitrary bogus value,
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

Have MediaPlayer supports files with unknown duration:
* Controller: accept streams with unknown duration.
* PlaybackManager: trusts the current frame start and end when frameCount not positive. Also don't stop playing when fStopPlayingFrame is zero.
* MediaTrackAudioSupplier: only fills with silent when the frame count is not zero.
* added some traces.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31569 a95241bf-73f2-0310-859d-f6bbb57e9c96

Improved error logging.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31476 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fixed CID 1297: the buffList array was never deleted.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27432 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Move the color_space_to_string() function into it's own file.
* On BeOS "bitmaps_support_space()" returns false for YCbCr color spaces. :-(
* Refactor the code which sets up the decoded format in the MediaTrack-
VideoSupplier to always start with a clean format for multiple calls to
BMediaTrack::DecodedFormat().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25824 a95241bf-73f2-0310-859d-f6bbb57e9c96

Do not reference bitmap color spaces directly anymore, but use
bitmaps_support_space() interface kit function. First try to
use overlays, if that fails, try again without overlays. The
NodeManager makes sure to fall back to B_RGB32 if the given
mode is not supported for drawing bitmaps in by BViews. Thanks,
Axel, for the suggestion!


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25764 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Support codecs that don't support B_YCbCrXXX color spaces.
* Leave the codec a chance to advertise the best output color space,
try B_YCbCr422 as the most widely supported format in case the codec
does not advertise.
* Support two more overlay colorspace modes in the video consumer.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25731 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved a bunch of non-primary interface classes into a new subfolder
"interface"

* Complete reimplementation of the playback engine using Media Nodes:
- Seeking video files does not appear to lockup the playback anymore, but
works on a frame accurate level even for keyframe based streams. There is
currently a problem with certain container formats, the audio track reports
a "Device Seek Error" in certain conditions. In that case audio goes silent,
and can be restarted by going back to the beginnings of the stream.
- Video overlays are now supported.
- It would be possible to connect the output of the MediaPlayer to other
applications or dormant media nodes.

* Known regressions:
- The volume slider has currently no effect anymore.
- Switching the audio track during playback has a known race condition and
can crash the player.
- The new engine is not as "light weight" as the old one. I tagged the
previous implementation in tags/components/mediaplayer-engine-v1. It does
not seem to have any noticable effect though.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25725 a95241bf-73f2-0310-859d-f6bbb57e9c96