VideoCapture QuickTime file reader returns frames out of order (Bug #2579)
The QuickTime implementation of VideoCapture file reader (CvCaptureFile) in cap_qtkit.mm returns the frames in this order: 2, 3, 4, ..., N, N, 1.
Note that the first frame is returned last and that the last frame is returned twice. This is when VideoCapture is trivially used in a loop to read frames one by one with the >> operator.
Looking at the implementation of CvCaptureFile::grabFrame() in cap_qtkit.mm:676 I suspect that the [mCaptureSession stepForward] call is causing this because it's called even for the first grab call.
- What is your operating system? Which version of OpenCV are you using?
- Do you have a video, where you can see the frame number? If you have such, please attach, this will simplify the process.
- A short reproducing sample would be also helpful. I understand that it is trivial, but please attach it if you have, this may help a little bit.
- It seems that you have a guess about the root cause... Is it possible you to debug the issue and provide a pull request? Otherwise it may too long before somebody has time to look into this issue.
- Target version set to 2.4.4
- Assignee changed from Vadim Pisarevsky to Mohammad Toossi
Thanks for your prompt response.
- OS X 10.8.2 with a fresh OpenCV trunk build at 7f542e391a
- I have attached a video with 10 frames which show numbers 0-9
- Also attached sample code that displays one frame with each key press. Another issues that I didn't mention in the original bug report is that the video cycles around. It doesn't return an empty frame at end of video, unlike in other implementations.
- Unfortunately, I'm completely unfamiliar with QTKit. It would take me much longer to properly fix this than it took me to file this report. Also, note that the [mCaptureSession stepForward] call only explains one part of the bug (starting with frame 2). It doesn't explain the strange behavior at the end of video and cycling around, although I suspect that wouldn't be too hard to debug either.