History log of /haiku/src/apps/mediaplayer/media_node_framework/PlaybackManager.h
Revision Date Author Comments
# 0beac2ff 09-Sep-2010 Stephan Aßmus <superstippi@gmx.de>

PlaybackManager:
* Make sure that the messages which trigger a performance
time update a) don't pever pile up and b) that we don't
still receive an event after reinitialization (would
not have been a problem, at one point I thought it was).
* Don't compile in support for changing the playback speed
for the moment.
* Better support for notifying the reaching of a seek frame,
In _UpdateStates(), the wrong state (most often out of bounds)
was checked to be a seek request state. Check if a seek request
was reached in all other cases where states are removed.

Controller:
* Simple but important simplification of the problem that
seeked frames are reached asynchronously and with a latency:
In TimePosition() simply report the seeked frame, if there
are still pending seek requests. This allows a consistent
view from the outside, i.e. after calling SetTimePosition(),
TimePosition() will not return something different.
* Use a more robust way to track pending seek requests. A
new request may have been issued while not having reached
the previous one yet.
* Implement a notification for reaching the seek frame, but
I didn't need it after all, may come in handy later...

MainWin:
* Change the cursor left/right keys to support winding.
Cursor up/down change the volume, Cmd-up/down skips
to the previous/next playlist item, left/right do the
winding now, as requested in ticket #2495.


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


# 818577b2 06-Sep-2010 Stephan Aßmus <superstippi@gmx.de>

* Make PlaybackManager::CurrentFrame() return int64, like
what it's internally using. Adapt NotifyCurrentFrameChanged()
implementors.
* Controller::SetTo() does not need to set the current frame,
since either Init() or FormatChanged() will have taken care
of it now.
* Reset the seeking request info in Controller::SetTo().
* Changed the parameter passed to VideoSupplier::FillBuffer()
from media_format to media_raw_video_format, so the
VideoProducer doesn't have to generate a media_format for
each frame...
* ProxyVideoSupplier caches the last produced frame, which
avoids a situation that the VideoProducer asks to generate
the same frame twice sometimes.
* In PlaybackManager::_PushState(), make sure we really
schedule the next current_frame if asked. This avoids
one situation in which the VideoSupplier was asked to generate
the same frame again and fixes playback after pausing (was
showing black video until the next keyframe before.


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


# ab18a502 16-Nov-2009 Stephan Aßmus <superstippi@gmx.de>

* Moved the about alert handling into the application
* Simplified the handling of the first window and removed FirstWindow(),
we can tell by fPlayerCount.
* Both the above would fix a crash when requesting the about alert with the
first window already gone. Respectively another player instance opening
if fFirstWindow was reset to NULL after some recent revision.
* Implemented restoring the current playlist, index and position in the file.
* Devised a more robust way to solve asynchronous seeking. The Controller is
now notified that a seek request has been handled with a dedicated hook.


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


# eb91d005 14-Jul-2008 Stephan Aßmus <superstippi@gmx.de>

* Whether an audio and/or video node is used is now more explicit. The audio
node can now also be turned off for videos that don't have audio.
* The PlaybackManager currently has the "no audio" support added in a not
quite so nice way, will have to think about something, this is just quick
and dirty to get it going. There is just two places where the audio time
needs to be ignored, because it remains at zero.

-> Especially when using OSS, the seeking latency will be much reduced when
playing videos that have no sound.

* The Controller now maintains the frame it wanted to seek to and does not
forward "position changed" to other listeners as long as the seek frame
has not been reached. This fixes the slider jumping back to the old position
for a bit until jumping back to the seek frame. It also fixes another
problem when switching to the next file. Because the total duration is
already adopted while the old clip is still playing within the seek latency,
the current position jumped to the new relative position, while it is
still refering to the position within the old clip. So both seeking and
switching clips looks much smoother now.


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


# 0fc56ed5 30-May-2008 Stephan Aßmus <superstippi@gmx.de>

* 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


# 0beac2ff048390fecd8a08a99e7dd2cd8a9724b4 09-Sep-2010 Stephan Aßmus <superstippi@gmx.de>

PlaybackManager:
* Make sure that the messages which trigger a performance
time update a) don't pever pile up and b) that we don't
still receive an event after reinitialization (would
not have been a problem, at one point I thought it was).
* Don't compile in support for changing the playback speed
for the moment.
* Better support for notifying the reaching of a seek frame,
In _UpdateStates(), the wrong state (most often out of bounds)
was checked to be a seek request state. Check if a seek request
was reached in all other cases where states are removed.

Controller:
* Simple but important simplification of the problem that
seeked frames are reached asynchronously and with a latency:
In TimePosition() simply report the seeked frame, if there
are still pending seek requests. This allows a consistent
view from the outside, i.e. after calling SetTimePosition(),
TimePosition() will not return something different.
* Use a more robust way to track pending seek requests. A
new request may have been issued while not having reached
the previous one yet.
* Implement a notification for reaching the seek frame, but
I didn't need it after all, may come in handy later...

MainWin:
* Change the cursor left/right keys to support winding.
Cursor up/down change the volume, Cmd-up/down skips
to the previous/next playlist item, left/right do the
winding now, as requested in ticket #2495.


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


# 818577b203870d5b3625514a99c35726f42cbde3 06-Sep-2010 Stephan Aßmus <superstippi@gmx.de>

* Make PlaybackManager::CurrentFrame() return int64, like
what it's internally using. Adapt NotifyCurrentFrameChanged()
implementors.
* Controller::SetTo() does not need to set the current frame,
since either Init() or FormatChanged() will have taken care
of it now.
* Reset the seeking request info in Controller::SetTo().
* Changed the parameter passed to VideoSupplier::FillBuffer()
from media_format to media_raw_video_format, so the
VideoProducer doesn't have to generate a media_format for
each frame...
* ProxyVideoSupplier caches the last produced frame, which
avoids a situation that the VideoProducer asks to generate
the same frame twice sometimes.
* In PlaybackManager::_PushState(), make sure we really
schedule the next current_frame if asked. This avoids
one situation in which the VideoSupplier was asked to generate
the same frame again and fixes playback after pausing (was
showing black video until the next keyframe before.


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


# ab18a502299fa5a8d32768b07814836ef365380b 16-Nov-2009 Stephan Aßmus <superstippi@gmx.de>

* Moved the about alert handling into the application
* Simplified the handling of the first window and removed FirstWindow(),
we can tell by fPlayerCount.
* Both the above would fix a crash when requesting the about alert with the
first window already gone. Respectively another player instance opening
if fFirstWindow was reset to NULL after some recent revision.
* Implemented restoring the current playlist, index and position in the file.
* Devised a more robust way to solve asynchronous seeking. The Controller is
now notified that a seek request has been handled with a dedicated hook.


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


# eb91d0058dead0e6f8dc79cc531907fb31012b6b 14-Jul-2008 Stephan Aßmus <superstippi@gmx.de>

* Whether an audio and/or video node is used is now more explicit. The audio
node can now also be turned off for videos that don't have audio.
* The PlaybackManager currently has the "no audio" support added in a not
quite so nice way, will have to think about something, this is just quick
and dirty to get it going. There is just two places where the audio time
needs to be ignored, because it remains at zero.

-> Especially when using OSS, the seeking latency will be much reduced when
playing videos that have no sound.

* The Controller now maintains the frame it wanted to seek to and does not
forward "position changed" to other listeners as long as the seek frame
has not been reached. This fixes the slider jumping back to the old position
for a bit until jumping back to the seek frame. It also fixes another
problem when switching to the next file. Because the total duration is
already adopted while the old clip is still playing within the seek latency,
the current position jumped to the new relative position, while it is
still refering to the position within the old clip. So both seeking and
switching clips looks much smoother now.


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


# 0fc56ed57bdd5d2d44f33edd17d94210704613bd 30-May-2008 Stephan Aßmus <superstippi@gmx.de>

* 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