17 replies to this topic

[Taapat]

Users complain and I also observe problems with a pause on mkv files on gstreamer-0.1.

When I press the pause button, the image stops, but the movie time skips the a few minutes ahead.

When I start playing the movie will continue not from the place where I stopped, but from this time a few minutes ahead.

 

This problem I do not have on receiver with gstreamer-1. On gstreamer-1 pause works without problems.

I think that this commit not work as intended on gstreamer-0.1: https://github.com/O...21da8f6826ec678

[christophecvr]

Users complain and I also observe problems with a pause on mkv files on gstreamer-0.1.

When I press the pause button, the image stops, but the movie time skips the a few minutes ahead.

When I start playing the movie will continue not from the place where I stopped, but from this time a few minutes ahead.

 

This problem I do not have on receiver with gstreamer-1. On gstreamer-1 pause works without problems.

I think that this commit not work as intended on gstreamer-0.1: https://github.com/O...21da8f6826ec678

It is possible, but I doubt however I could set it only for gst-1.0. What I well know is that by me the pause never worked ok in the days I was using gstreamer-0.1 (some mkv it worked but most not)

 

Did You try on gst-0.10 with :

https://github.com/O...ree/next-master

 

guess this will solve pause issue

[christophecvr]

@Taapat did You tried it ?

 

I do have a patch ready to have the commit :

https://github.com/O...21da8f6826ec678

 

only for gst-1.0 but gues the next master should work:

 

I'll put here the patch (first the one which is actually in next-master could be that this solve all pause issues on gst-0.1 just like it does on gst-1.0.

This patch covers two issues:

- Some mkv's with reduced video quality do loss track off audio when pausing result is a stucked pipeline into state playing pending paused Only solution there is weather to stop media or pipeline unblocks when the active audiotrack is reselected.

  vuplus series do have problems with this on other box I have dm8000 very rare but it happens so what in 2 to 3 % off cases by some mkv media .

- Rapid fingers especially on fast stb's very quick pause unpause(double push on pause/unpause button) , the result is that the gstreamer is in paused while enigma2 is in play. Unpause impossible only media stop helps.

  After the patch the rapid finger causes same but by repushing button e2 will go in pause and gstreamer remains in pause pause flag will come and media can be unpaused normally.

  This all whitout loosing current play position.

 

The second patch is the one which I will send by pull request if the patch which is on next-master does not work for gst-0.10.

 

 

 

 

Attached Files

•  E2-serviceMP3-pause-unpause-issue.patch   4.27KB   2 downloads
•  E2-state-update-during-paused-only-for-gst1.patch   2.33KB   1 downloads

[Taapat]

@christophecvr I am very sorry, but I really do not want to change gstreamer version on 0.1 to check this.
For myself on solo2 I builds image with gstreamer 1.

 

On zgemma I use the original openpli-4 and on it is this pause problem.
But I do not want to spend the time to build the original openpli-4 branch master, because the problem is directly on it, and I think that needs to test how work gstreamer 0.1 on branch master.

[christophecvr]

@christophecvr I am very sorry, but I really do not want to change gstreamer version on 0.1 to check this.
For myself on solo2 I builds image with gstreamer 1.

 

On zgemma I use the original openpli-4 and on it is this pause problem.
But I do not want to spend the time to build the original openpli-4 branch master, because the problem is directly on it, and I think that needs to test how work gstreamer 0.1 on branch master.

Sorry thaught You had still a openpli-4 build with gst-0.10 . But I also have no build anymore with gst-0.10 . I even only use master-next openpli-oe-core and gstreamer-1.9.0.1

 

Then I just send pull request from patch to make that last only for gst-1.0 (however I always had the very same problem with most mkv's the day's I used gst-0.10 that was well more then two years ago).

Edited by christophecvr, 15 May 2016 - 14:07.

[christophecvr]

small note : there is also a work-around upon change off audiotrack to reposition a bit earlier, That procedure is required on gst-0.10 but not on gst-1.0 .

[mx3L]

 

When I press the pause button, the image stops, but the movie time skips the a few minutes ahead.

When I start playing the movie will continue not from the place where I stopped, but from this time a few minutes ahead.

When you pause, we are taking position from playbin and not from sinks and playbin's position is ahead of position provided by sinks when HW buffers are not empty. Unpause in gstreamer-0.10 is done by seeking to current position and current position is playbin's one, so it will seek to it and not just unpause pipeline as in gstreamer1.0.

 

 

This problem I do not have on receiver with gstreamer-1. On gstreamer-1 pause works without problems.

When you pause, position should jump ahead like in gstreamer-0.10 and on unpause it should jump back again.

 

 

 

[Taapat]

I have not watched what is in the log, but I take time information from infobar.

 

On the original openpli-4 with gstreamer-0.1 on pause time jumps for many minutes.
On gstreamer-1 time jumps only by 1 second.

 

Therefore, on image with the gstreamer-1 I do not see any problem, but on the original openpli-4 pause do not work as expected.

[christophecvr]

Well actually.

 

with gst-1.0 when we pause or unpause , we do not change the playposition. We do not flush the buffers. We do not loose anything. But when we do an action during paused state yes then we take the playbin position. But with the position correction on the playbin we loose nothing.

 

Taapat was speaking about a few minutes that's much more then the buffers. So most be something else.

Edited by christophecvr, 15 May 2016 - 14:38.

[Taapat]

Taapat was speaking about a few minutes that's much more then the buffers. So most be something else.

 

It may be that the cause is not your patch, but I really do not see any other commit that could affect it.

 

I for file playback not use zgemma receiver and checked the problem only after a user complained about it.

Maybe that this problem has existed for a long time. But users report that on 2 may image, this problem does not exist.

[christophecvr]

 

Taapat was speaking about a few minutes that's much more then the buffers. So most be something else.

 

It may be that the cause is not your patch, but I really do not see any other commit that could affect it.

 

I for file playback not use zgemma receiver and checked the problem only after a user complained about it.

Maybe that this problem has existed for a long time. But users report that on 2 may image, this problem does not exist.

 

Yes it could be , That's why I send pull request to set commit only for gst-1.0 after all that will be the future anyway once master-next will become the beta image. So guess it's a bit waist off time trying to improve the gst-0.10 mkv playing when actually gst-0.10 is more deprecated code then something else . Also suspect a bug concerning this mather in gst-0.10. Since I can't test gst-0.10 ....

[christophecvr]

note on :

 

 

with gst-1.0 when we pause or unpause , we do not change the playposition. We do not flush the buffers. We do not loose anything

That is a fact in despit the playbar gives 1 second more in reality you loose 0.0

[mx3L]

This is pause/unpause behaviour in gstreamer1.0:

< 65006.160> getPlayPosition (sink) = 0:05:33.812661840
< 65006.353> getPlayPosition (sink) = 0:05:34.004659920
< 65006.850> getPlayPosition (sink) = 0:05:34.508654880
< 65007.353> getPlayPosition (sink) = 0:05:35.012649840
< 65007.755> action ->  MediaPlayerActions pause
< 65007.759> resolved to PAUSE
< 65007.884> getPlayPosition (sink) = 0:05:35.444645520
< 65007.895> getPlayPosition (sink) = 0:05:35.444645520
< 65007.904> getPlayPosition (sink) = 0:05:35.444645520
< 65008.348> getPlayPosition (playbin) = 0:05:32.405651791
< 65008.390> getPlayPosition (playbin) = 0:05:32.405651791
< 65008.407> getPlayPosition (playbin) = 0:05:32.405651791
..........
< 65025.848> getPlayPosition (playbin) = 0:05:32.405651791
< 65025.889> getPlayPosition (playbin) = 0:05:32.405651791
< 65025.896> action ->  MediaPlayerActions pause
< 65025.901> resolved to PLAY
< 65026.035> getPlayPosition (playbin) = 0:06:42.816000000
< 65026.043> getPlayPosition (playbin) = 0:06:42.816000000
< 65026.052> getPlayPosition (playbin) = 0:06:42.816000000
< 65026.057> getPlayPosition (playbin) = 0:06:42.816000000
< 65026.068> getPlayPosition (playbin) = 0:06:42.816000000
< 65026.078> getPlayPosition (playbin) = 0:06:42.816000000
< 65026.347> getPlayPosition (sink) = 0:05:35.588644080
< 65026.556> getPlayPosition (sink) = 0:05:35.804641920
< 65026.563> getPlayPosition (sink) = 0:05:35.804641920
< 65026.583> getPlayPosition (sink) = 0:05:35.828641680
< 65026.593> getPlayPosition (sink) = 0:05:35.852641440
< 65026.645> getPlayPosition (sink) = 0:05:35.900640960
< 65026.661> getPlayPosition (sink) = 0:05:35.900640960
< 65026.847> getPlayPosition (sink) = 0:05:36.092639040

There is jump which you can see also in UI just when you unpause to 0:06:42.816000000.

 

Weird thing is that there is little jump back to 0:05:32.405651791 when you pause and position is taken from playbin, since it should be ahead like after unpause - 0:06:42.816000000.

[christophecvr]

Well Yes it's a bit weird We should expect the playbin to be a bit further.

 

I well did tremendous tests just with own perception (human is not that fast as a computer on this point). But as well for image and or audio I can't see any position back or further when pausing or unpausing on gst-1.0 by a movie self at this time.

 

What is also interesting :

< 65007.904> getPlayPosition (sink) = 0:05:35.444645520
< 65008.348> getPlayPosition (playbin) = 0:05:32.405651791
................
< 65026.078> getPlayPosition (playbin) = 0:06:42.816000000
< 65026.347> getPlayPosition (sink) = 0:05:35.588644080

The last sink position after pause and the first after unpause +- 0.144 second.

[littlesat]

I would suggest we concentrate here on next-master.... then probably we can also remove the conditional compiling for gstr < or >= 1.0....

[christophecvr]

I would suggest we concentrate here on next-master.... then probably we can also remove the conditional compiling for gstr < or >= 1.0....

that is a good idea , but what well is : the current master enigma2 is very alive. If we are working with next-master in the test images and next master stays behind the master eventual improvements let's say into the mediaplayer.py or some modules like movieselection.py hdd slection and .. which have a change in master but by also other's related to gst-1.0 into next-master only could cause conflicts.

[littlesat]

I did just merged master into next-master.... when needed please ask it here...

[Erik Slagter]

I do it almost always once a week, that should be enough imho.