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>

Use the exact time the event was supposed to fire,
not the current real time. If I understand things
correctly, using the mechanism to send a MessageEvent
is just there to invoke SetPerformanceTime() within
the PlaybackManager BLooper (I could be mistaken).
Need to check whether this fixes a drift in audio
and video I am often observing.


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

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

* 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

* Minor cleanup, no functional changes.


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

* 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

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

Fixing all headers/namespaces/name lookup problems that hinder a GCC 4.3.2
build. I sure hope that this doesn't break the build for anyone else.


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

Fix this bug in the correct spot by forbidding the controller from trying to toggle the playback state if it hasn't been initialized with a file. Thanks for the tip, Stephan!



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

Style cleanup.
When asked to toggle playback, PlaybackManager never checked if it had a previous playback state to copy from. This caused a crash if playback was toggled via the keyboard when no file was loaded. Fixes ticket #2664 .


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

* 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

Minor changes to debug output, I was trying to track something down, actually
a problem in the OSS media node which also affects at least the ZETA 1.2
MediaPlayer on ZETA.


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

Do not insert a new playing state when seeking to the same frame. In the
end, this results in trying to decode the last frame again, which would
the decoder to seek unnecessarily.


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

Small code cleanups.


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

Use the exact time the event was supposed to fire,
not the current real time. If I understand things
correctly, using the mechanism to send a MessageEvent
is just there to invoke SetPerformanceTime() within
the PlaybackManager BLooper (I could be mistaken).
Need to check whether this fixes a drift in audio
and video I am often observing.


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

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

* 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

* Minor cleanup, no functional changes.


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

* 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

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

Fixing all headers/namespaces/name lookup problems that hinder a GCC 4.3.2
build. I sure hope that this doesn't break the build for anyone else.


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

Fix this bug in the correct spot by forbidding the controller from trying to toggle the playback state if it hasn't been initialized with a file. Thanks for the tip, Stephan!



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

Style cleanup.
When asked to toggle playback, PlaybackManager never checked if it had a previous playback state to copy from. This caused a crash if playback was toggled via the keyboard when no file was loaded. Fixes ticket #2664 .


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

* 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

Minor changes to debug output, I was trying to track something down, actually
a problem in the OSS media node which also affects at least the ZETA 1.2
MediaPlayer on ZETA.


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

Do not insert a new playing state when seeking to the same frame. In the
end, this results in trying to decode the last frame again, which would
the decoder to seek unnecessarily.


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

Small code cleanups.


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