#
f27269a6 |
|
14-Jul-2020 |
X512 <danger_mail@list.ru> |
MediaPlayer: fix reporting wrong format Now it allows to connect MediaPlayer video producer to differnt node in Cortex. Change-Id: I7ee598ea64d10e8fa876259e7a4480a650a0e189 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3034 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
|
#
892e4f21 |
|
15-Sep-2010 |
Stephan Aßmus <superstippi@gmx.de> |
* Changed the VideoSupplier interface to allow forcing the 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
|
#
f7eb8be9 |
|
15-Sep-2010 |
Stephan Aßmus <superstippi@gmx.de> |
* Instead of using some bogus latency for the VideoProducer, 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
|
#
c3f9ae12 |
|
14-Sep-2010 |
Stephan Aßmus <superstippi@gmx.de> |
Set the processing latency using the time it took to decode the last frame. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38653 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
|
#
2cc22e8a |
|
01-Sep-2010 |
Stephan Aßmus <superstippi@gmx.de> |
Don't try to decode more than 5 frames at a time to reach the seek frame. It's just not such a good strategy, since it appears to be faster to just wait until the next keyframe is reached naturally. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38506 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
6d0505ff |
|
06-Jun-2008 |
Stephan Aßmus <superstippi@gmx.de> |
The seeking algo stopped decoding frames one frame too early. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25819 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4aa9ff58 |
|
31-May-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Fix a locking problem with inner locks to protect the race condition when the producer media nodes would access the suppliers in their own thread without having any locks held, while the window could replace the suppliers. I think since I delayed the deletion of the suppliers in the controllers, this problem was only theoretical... but this is just more clean. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25734 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
|
#
892e4f21be74818d65a85f3ee76b07b51e814d46 |
|
15-Sep-2010 |
Stephan Aßmus <superstippi@gmx.de> |
* Changed the VideoSupplier interface to allow forcing the 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
|
#
f7eb8be9304cecb1575b1aa244aa39243c15bf17 |
|
15-Sep-2010 |
Stephan Aßmus <superstippi@gmx.de> |
* Instead of using some bogus latency for the VideoProducer, 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
|
#
c3f9ae128a303630c6afc8387d640c37d0e28c17 |
|
14-Sep-2010 |
Stephan Aßmus <superstippi@gmx.de> |
Set the processing latency using the time it took to decode the last frame. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38653 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
|
#
2cc22e8a26afe0dc90d0da6b276cc46dcc308f57 |
|
01-Sep-2010 |
Stephan Aßmus <superstippi@gmx.de> |
Don't try to decode more than 5 frames at a time to reach the seek frame. It's just not such a good strategy, since it appears to be faster to just wait until the next keyframe is reached naturally. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38506 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
6d0505fffc0e605e0e706ea937f95f32af8e66d1 |
|
06-Jun-2008 |
Stephan Aßmus <superstippi@gmx.de> |
The seeking algo stopped decoding frames one frame too early. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25819 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4aa9ff58c6392bee9f9dd7b4ef371d1bcd733cb1 |
|
31-May-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Fix a locking problem with inner locks to protect the race condition when the producer media nodes would access the suppliers in their own thread without having any locks held, while the window could replace the suppliers. I think since I delayed the deletion of the suppliers in the controllers, this problem was only theoretical... but this is just more clean. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25734 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
|