Probably you already noticed, that there is some strange behaviour when you pause and then unpause your media files with comparison to pause/unpause on your recordings. By strange I mean that you can clearly see that it's not unpaused from the same frame.
This is caused by doing flushing seek to the same position for unpause - it means that we first clear pipeline, then driver's buffers and then we seek to the same position as was in paused, which will refill the pipeline again.
Problem is that as you can see it's really not the same position, and it's not done immediately.
Why is it done this way?
I'm not sure, maybe because in gstreamer-0.10 more source timed out after long time in paused state or maybe because one of sink's didn't preroll, which caused pipeline to stall?
How to improve it?
I suggest we can just unpause pipeline for selected sources will not timeout (filesrc, souphttpsrc), when in paused state.
What are the issues?
Sometimes one of our sinks doesn't preroll(when going to paused state sink wants to make sure that it can play something immediately, therefore it waits for first buffer to arrive on it's sinkpad), this means that whole pipeline is blocked since sink cannot commit its state and we are stuck.
Why is it happening?
This is still a question to answer, but we can prevent it from happening by turning off async state changes for our sinks. It means that sinks will not wait for preroll when going to paused and then commit their state, but will commit their state immediately, without worrying if they are prerolled or not.
Why is async state change turned on?
I'm not sure, this is first commit where it was added:
When async state change is enabled, then when sink is going to paused state, it will return ASYNC state change and will wait until first buffer arives at its sinkpad, then it will commit state to PAUSED. This should be only important when we would synchronize buffers against clock, since sinks would only start to render when both were prerolled. I don't think we should care about this, we should fill driver buffers as fast as possible and let them do a synchronization.
What do you think?
Patches:
1. https://github.com/mx3L/enigma2/commit/1a3838843adb5896d51a1dd449b5492eed628b84
2. https://github.com/mx3L/gst-plugin-dvbmediasink-1/commit/2a81dcfe289edbcad5c8655b4990da56931b70a6
3. https://github.com/mx3L/gst-plugin-dvbmediasink-1/commit/4c0121a4d00db0fee5d779b1f74ed60a2a794e70
2. patch - probably this should be better set in servicemp3, so we don't force it in dvbmediasink
3. patch - is not neccessary but slightly improves seeking performance in vusolose(frames are not fastforward-ed after seeking for a few moments)
I did brief tests on vusolose on rtmp, http streams and local files, seeking pausing/unpausing, fastforward works flawlessly when all 3 patches were applied.