ffpyplayer video: better video seek

[germn]

Right now changing position of video with ffpyplayer is a bit buggy. Audio stream will seek correctly, while video stream will be slowed or speeded for few seconds before both streams became synchronized.

This PR fixes it making seeking much nicer. While ffpyplayer doc says this method is "inaccurate", on practice it works better given us very close position to wanted and synchronized streams momentarily.

I tested it on Windows and Android on different videos for a long time.

[matham]

The problem with this is that some videos only have I-frames at regular intervals of e.g. 5 or 10 seconds. When accurate is False, it'll only seek to the closest I-frame which means that you may be as much as 5s or 10s away from your seek point. Try it with videos with large distances between their I-frames.

[germn]

@matham, yes, I know it, but I think it's better to use inaccurate seek on practice. When we seek accurately we will wait same 5-10 second seeing slowed/speeded video stream. It's confusing, I'm not sure it worth it.

It's debatable issue, but I can notice that gstreamer also uses inaccurate seeking and we'll will at least get similar behavior for different providers.

Long story short, I like inaccurate seeking much more. Feel free to accept or reject this PR.

P.S. Sorry if I'm being annoying, couldn't you also take a look when you have time at this ffpyplayer-related PR? I use it for a long time and it works fine for me.

[matham]

Ok, a better solution then is to add a def seek(self, percent, precise=True): and save the precise flag in the queue as a tuple along with percent and use that. That way, the current behavior remains default but you can overwrite it.

Remember to add docs for the meaning and implication of using the precise flag though.

[germn]

precise flag added.

[matham]

The reason for copy and then delete is because of threading issues. If you get the last value and then delete all elements, because this runs in a second thread, in between the get and delete a new seek may have been added from the other thread. So you end up losing that seek request. The way it was before (copy and then delete the number of copied elements) is thread safe so please change it back to that.