What I do not understand is that you "play" with (a)sync in gstreamer while in fact "behind" gestreamer the hardware buffer (and driver) guaranteed messed up with the "buffer".... So I do not understand how this could fix the pauze performance....???? How does it work-a-round that hardware (driver) buffer???
There is no workaround hardware (driver) buffer. When doing unpause in servicemp3 we are doing flush seek to current position.
flush seek to current position:
1. discards buffers in pipeline + discards buffers in driver buffer
2. source is set to current position, new buffers starts to flow through pipeline into sink and driver buffer.
I suggest to not to do flush seek to current position when unpause, but only unpause pipeline. There is no need to discard valid buffers, we just need to continue to push buffers to driver buffer after unpause.
With this said it should be now clear why it improves unpause performance, i.e we don't have to re-fill pipeline after flush seek with new buffers, but seamlessly continue in playback.
This is done in servicemp3 patch + fallback to flush seek to current position, in case pipeline is not in valid state or unpause is not used on supported sources.
but I still do not understand why the latest commit suggestion should solve it.... (it might be I miss the clue)
When we pause pipeline, sometimes happens that it's afterwards not in valid state. We cannot unpause pipeline from not valid state.
Not valid state means, that it's not in PAUSED state and has pending state set to PAUSED, which needs to be commited first, in order for state to be valid.
State of pipeline is defined by it's elements. I found out that problematic element which causes this state is dvbaudiosink. dvbaudiosink is in this state, because it waits for preroll buffer, which never comes.
By turning off async state changes in dvbaudiosink, we make sure that it will never get into this state, because it will no longer care when this preroll buffer comes, but will commit new state immediately. -> pipeline should be always in valid state when unpausing, i.e. fallback option to flush seek to current position, will be not used.
http://gstreamer.fre...t-async-enabled
Configures sink to perform all state changes asynchronously. When async is disabled, the sink will immediately go to PAUSED instead of waiting for a preroll buffer. This feature is useful if the sink does not synchronize against the clock or when it is dealing with sparse streams.
Summary:
servicemp3 patch:
should be enough, but when unpausing it sometimes fallbacks to flush seek to current position, when pipeline is not in valid state.
If this happens on Vu+ it sometimes triggers some kind of bug, which causes to stop video rendering and only audio can be heared, while A/V buffers are flowing to sinks but are far apart(pts).
async patch:
makes sure that we have pipeline always in valid state after pause, so no fallback to flush seek to current position happens -> always seamless unpause, assumed Vu+ bug in drivers is not triggered.
Patches were tested on et4x00, vusolose and vuduo2(@christophecvr)
Edited by mx3L, 19 November 2015 - 14:49.