Don't seek in VideoManager start() unless required

[dadus33]

Seeking the video by using cv2's CAP_PROP_POS_FRAMES property is not guaranteed to be accurate, and has caused issues for me numerous times. One such example is trying to seek to a certain frame within a video resulted from the concatenation of several transport stream files, when the first video is small (eg. 1.ts - 5 frames, 2.ts - 500 frames -> seeking to frame 0, 1, 2, 3, or 4 would in fact seek to frame 5 - which corresponds to frame 0 from 2.ts and thus entirely skip all the frames in 1.ts).

In my case, seeking is simply not necessary, and not doing it ensures the whole video is processed, so I suggest simply not seeking the video if the start timecode is 0.

However, to really fix this, a new way to seek is necessary. If using OpenCV, simply calling VideoCapture.read() (grab() might work too, and would definitely be faster) until the desired frame number is reached should work. This would however be slower than setting the CAP_PROP_POS_FRAMES property, so maybe making accurate seeking optional (via a parameter to seek() or the VideoManager itself perhaps?) would work best.

For now though, simply not seeking at all when the start timecode is 0 would be an improvement, at least in my situation.

[Breakthrough]

This is likely related to #213, so feel free to provide your input there as well (the suggestion is to use PyAV instead of OpenCV to do the video seeking).

Thank you for the PR, this will be included in v0.5.6.

[dadus33]

Thank you for accepting the PR! Unfortunately I have very little experience with PyAV, but I think it would be worth looking into. Also, another library that might be helpful is Decord. It offers accurate seeking that is also very fast, even compared to PyAV (from their stats at least, didn't try PyAV's seeking).