#
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
|