History log of /haiku/src/apps/mediaplayer/media_node_framework/video/VideoProducer.cpp
Revision Date Author Comments
# 425ac1b6 20-Jun-2023 Alexander von Gluck IV <kallisti5@unixzen.com>

refactor: Swap %Ld for %lld in all format usages

* %Ld is an undocumented alias for %lld in glibc.
* muslc doesn't implement it for this reason.
* While we will likely never drop %Ld support,
lets clean house and set a better example.

Change-Id: Id46dad3104abae483e80cc5c05d1464d3ecd8030
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6636
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>


# 1c889d23 03-May-2020 Adrien Destugues <pulkomandy@pulkomandy.tk>

ffmpeg/MediaPlayer: fix seeking in audio with cover art

MediaPlayer is basing its time on both the audio and video frames. This
doesn't go so well when there is a single video frame, resulting in the
whole file being one single "timepoint".

Avoid this problem by having the video decoder set the frame time to
"infinite" when the video stream is finished, which allows for the audio
timings to be used in this case.

Also improve the framerate handling of ffmpeg further, to avoid
MediaPlayer trying to frameskip at 90000fps (it would give up
frameskipping after a few frames and eventually notice that the next
frame was the end of stream, but still, not very clean). Now we report
an FPS of 0 instead, which should make it clear to applications what to
expect from single-frame files.

It seems the cover art is now hidden by a black screen, I'm not sure
why. But I'll leave debugging this for another day.

Fixes #13622.

Change-Id: Ie1dd1358cbb41c11649103dfce52a0e1317b26f8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2562
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>


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


# 6cc8d65e 16-Jul-2019 Adrien Destugues <pulkomandy@pulkomandy.tk>

PVS V593: missing parentheses

Change-Id: I717b13ebf9b5e2436842cfadab757187529567f2
Reviewed-on: https://review.haiku-os.org/c/1613
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>


# 6c73846a 23-Sep-2018 Augustin Cavalier <waddlesplash@gmail.com>

MediaPlayer: Quit the VideoProducer when we reach the last buffer.

Fixes #13622.

The "media_node_framework" is such a huge mess. We really should sit down
and design a MediaKit2 someday that doesn't require ~15,000 lines of media
node support code just to have a "fully functioning media player."


# 7e74eb0f 02-Aug-2015 Dario Casalinuovo <b.vitruvio@gmail.com>

MediaPlayer VideoProducer: Flush event on stop


# 23b5556f 15-Jun-2015 Adrien Destugues <pulkomandy@gmail.com>

VideoProducer: fix the fix.


# 854d187f 15-Jun-2015 Adrien Destugues <pulkomandy@gmail.com>

VideoProducer: fix 64bit build.


# c6ffa94f 14-Jun-2015 Adrien Destugues <pulkomandy@gmail.com>

MediaPlayer: style fixes, print performance time of dropped frames

* Helps understanding why the frames get dropped in some cases, where
the computed performance time is not correct.


# 843a122f 04-May-2013 Jérôme Duval <jerome.duval@gmail.com>

MediaPlayer: some 64 bit fixes


# 5c6b9eb0 23-Feb-2012 Jerome Duval <jerome.duval@gmail.com>

Some fixes for GCC 4.6 warning: variable set but not used


# d174a87e 17-Sep-2010 Stephan Aßmus <superstippi@gmx.de>

If we still have our own BBufferGroup separate from
the used BBufferGroup (from consumer), make sure to
delete that one as well.


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


# b524af7e 16-Sep-2010 Stephan Aßmus <superstippi@gmx.de>

In case of time-out to generate a frame, leave the last
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


# 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


# 8eb72c72 15-Sep-2010 Stephan Aßmus <superstippi@gmx.de>

Fixed warning.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38663 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


# 5aaa0208 14-Sep-2010 Stephan Aßmus <superstippi@gmx.de>

The max time to take for rendering is arbitrary,
might as well take an even value.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38654 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


# b289aaf6 12-Apr-2010 Axel Dörfler <axeld@pinc-software.de>

* A BBuffer does not know where it came from, so
BBufferConsumer::BufferReceived() cannot know whom to send the "buffer is
late" notification (unless we only have a single input). To solve this, the
media_header now contains extra fields that can be used to create a
media_source object.
* Unfortunately, BBufferProducer::SendBuffer() cannot know the output either in
case there is more than one. Hence, I deprecated the existing SendBuffer()
call and moved it into "private" - IOW old sources using it won't compile
anymore under Haiku.
* I introduced a new SendBuffer() variant that also gets the media_source as
argument.
* Updated all sources (that are part of the image) to use the new variant.
* Removed some purposely commented out code in the audio mixer.
* Implemented late buffer notification, as well as late buffer handling in the
audio mixer; this is a bit of work in progress, so the debug output is left
in there.
* Some cleanup.


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


# 36c08853 16-Jul-2009 Stephan Aßmus <superstippi@gmx.de>

* Automatic white space cleanup
* Small hack to display at least some frames (one every 15 frames) when the
CPU is utterly incapable of decoding video fast enough.


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


# 591ce51a 09-Jul-2009 Stephan Aßmus <superstippi@gmx.de>

Improved error logging.


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


# 84b6bd9a 14-Aug-2008 David McPaul <dlmcpaul@gmail.com>

Correct display of Duration

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26976 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


# 7e74eb0f42d1c18b16dca999fbd4fd750a12cebb 02-Aug-2015 Dario Casalinuovo <b.vitruvio@gmail.com>

MediaPlayer VideoProducer: Flush event on stop


# 23b5556fe43948f5229dba7d9faf70c71cf8992b 15-Jun-2015 Adrien Destugues <pulkomandy@gmail.com>

VideoProducer: fix the fix.


# 854d187f2b72d5f2bdd94e2d4f374e17a0689a5d 15-Jun-2015 Adrien Destugues <pulkomandy@gmail.com>

VideoProducer: fix 64bit build.


# c6ffa94f5b9e6c9c378312e87631d6c1448c4699 14-Jun-2015 Adrien Destugues <pulkomandy@gmail.com>

MediaPlayer: style fixes, print performance time of dropped frames

* Helps understanding why the frames get dropped in some cases, where
the computed performance time is not correct.


# 843a122fd9a17bfde0f01db2c5660c33524bf40c 04-May-2013 Jérôme Duval <jerome.duval@gmail.com>

MediaPlayer: some 64 bit fixes


# 5c6b9eb00d0d623c12f72eb82a471cb4c71f4f33 23-Feb-2012 Jerome Duval <jerome.duval@gmail.com>

Some fixes for GCC 4.6 warning: variable set but not used


# d174a87e1ba5435e89cda22f478dddcb40b660cf 17-Sep-2010 Stephan Aßmus <superstippi@gmx.de>

If we still have our own BBufferGroup separate from
the used BBufferGroup (from consumer), make sure to
delete that one as well.


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


# b524af7e8132f518fca8388988cd0a43e2328aa5 16-Sep-2010 Stephan Aßmus <superstippi@gmx.de>

In case of time-out to generate a frame, leave the last
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


# 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


# 8eb72c72177b06b081a43dc70601549b7db95415 15-Sep-2010 Stephan Aßmus <superstippi@gmx.de>

Fixed warning.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38663 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


# 5aaa020871534459f9f973d85d5c220ea812fe2b 14-Sep-2010 Stephan Aßmus <superstippi@gmx.de>

The max time to take for rendering is arbitrary,
might as well take an even value.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38654 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


# b289aaf66bbf6e173aa90fa194fc256965f1b34d 12-Apr-2010 Axel Dörfler <axeld@pinc-software.de>

* A BBuffer does not know where it came from, so
BBufferConsumer::BufferReceived() cannot know whom to send the "buffer is
late" notification (unless we only have a single input). To solve this, the
media_header now contains extra fields that can be used to create a
media_source object.
* Unfortunately, BBufferProducer::SendBuffer() cannot know the output either in
case there is more than one. Hence, I deprecated the existing SendBuffer()
call and moved it into "private" - IOW old sources using it won't compile
anymore under Haiku.
* I introduced a new SendBuffer() variant that also gets the media_source as
argument.
* Updated all sources (that are part of the image) to use the new variant.
* Removed some purposely commented out code in the audio mixer.
* Implemented late buffer notification, as well as late buffer handling in the
audio mixer; this is a bit of work in progress, so the debug output is left
in there.
* Some cleanup.


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


# 36c088531f513ef265fae9a446e8c7cdf4cff0cb 16-Jul-2009 Stephan Aßmus <superstippi@gmx.de>

* Automatic white space cleanup
* Small hack to display at least some frames (one every 15 frames) when the
CPU is utterly incapable of decoding video fast enough.


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


# 591ce51a9c241fe99256fe9cbb20807d7bfbcfc5 09-Jul-2009 Stephan Aßmus <superstippi@gmx.de>

Improved error logging.


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


# 84b6bd9a95710ecff1d658e16078b6c3e57f7782 14-Aug-2008 David McPaul <dlmcpaul@gmail.com>

Correct display of Duration

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26976 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