Hello Sebastien,
I am quite aware of some seeking problems of the new version.
But I am no time to invesigate how to fix them.
The old version was just calling "av_seek_frame".
Basically, it was claiming to be ok, but if you checked
at the result it was returning. Actually, for many codecs,
it was returning a wrong frame for many calls.
The result returned by av_seek_frame was be far away
from exact frame number in stream.
I noticed two reasons therefore :
A) The declared initial_time_stamp is often not correct, or I don't know how to use it to make good initial seek.
Hence, the initial time_stamp has to be evaluated manually.
B) Sometime, it apperared to me, that the fact we pass from a conversion from "frame number" to "PTS",
was a reason for creating inaccuracy in the seek. More over on some CODEC, if you seek on a specified
frame, you actually ends up at the "NEXT" key frame.
To correct this behaviour in B I implemented the seeking a little bit before, and then to proceed to a normal playing and stop once the buffer are filled with data that have timestamps greater than the required timestamp.
However, sometime this does not work as expected.
To avoid to B), and to seek "as before", you may pass two options at the creation at the player :
{{{
vr=FFMpegPlayer(False,0)
}}}
------------------------------------------------------------------------------------------------------------------------------------------
There is another issue with short files or for images that are close to the end of the file.
The player because it aimed at being a multimedia player, that will let you access the audio that is
listened during a specified frame, will always try to look at a little bit after the image you are reading,
in order to push all the consecutive audio in the audioqueue.
However, here I shall add some exception handling there, to avoid to crash before the real end-of-the-file.
I haven't :
Hence :
{{{
self.prepare_to_be_just_in_time()
}}}
Shall be replaced by :
{{{
try:
self.prepare_to_be_just_in_time()
except IOError:
pass
}}}
-----------------------------------------------------------------------------------------------------------------------------------
Note that this also disabled by
{{{
vr=FFMpegPlayer(False,0)
}}}
-----------------------------------------------------------------------------------------------------------------------------------
Finally, there is some refactoring to do on the variable names.
I refered to the last feature, by "just_in_time" in the code,
maybe there can be some better / more explicit name.
-----------------------------------------------------------------------------------------------------------------------------------
I believe it would be good to have robust seeking since we are often using pyffmpeg for research
purpose. So far most system that have a robust seeking are actually using indexes.
It was one of the track of the original code. But the indexes were not used actually in the
original code.
One good thing may also be to examine code of more complicated players that are famous
for their seeking such as "avidemux", but they have many backends, and do not rely only on
ffmpeg.
--------------------------------------------------------------------------------------------------------------------------------------
I hope this helps a little bit in understanding the new code.
Thanks for your initiative.
Bertrand