VideoCapture QuickTime file reader returns frames out of order (Bug #2579)


Added by Mohammad Toossi over 4 years ago. Updated over 1 year ago.


Status:Open Start date:2012-11-27
Priority:Normal Due date:
Assignee:Vadim Pisarevsky % Done:

0%

Category:highgui-video
Target version:Next Hackathon
Affected version:branch '2.4' Operating System:
Difficulty: HW Platform:
Pull request:

Description

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.


count.avi (21.7 kB) Mohammad Toossi, 2012-11-28 07:17 pm

sim.cc (435 Bytes) Mohammad Toossi, 2012-11-28 07:17 pm


History

Updated by Kirill Kornyakov over 4 years ago

Mohammad,

  1. What is your operating system? Which version of OpenCV are you using?
  2. Do you have a video, where you can see the frame number? If you have such, please attach, this will simplify the process.
  3. 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.
  4. 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

Updated by Mohammad Toossi over 4 years ago

Kirill,

Thanks for your prompt response.

  1. OS X 10.8.2 with a fresh OpenCV trunk build at 7f542e391a
  2. I have attached a video with 10 frames which show numbers 0-9
  3. 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.
  4. 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.

Updated by Kirill Kornyakov over 4 years ago

OK, thank you for all the information. We'll now wait for somebody to look into this issue. Any help is appreciated!

  • Assignee changed from Mohammad Toossi to Vadim Pisarevsky

Updated by Vadim Pisarevsky about 4 years ago

  • Target version deleted (2.4.4)

Updated by Vadim Pisarevsky about 4 years ago

  • Assignee deleted (Vadim Pisarevsky)

Updated by Vadim Pisarevsky about 4 years ago

  • Assignee set to Vadim Pisarevsky

Updated by Kirill Kornyakov about 4 years ago

  • Target version set to 2.4.4
  • Affected version set to branch '2.4'

Updated by Andrey Kamaev about 4 years ago

  • Target version changed from 2.4.4 to Next Hackathon

Updated by Maksim Shabunin over 1 year ago

Issue has been transferred to GitHub: https://github.com/Itseez/opencv/issues/4459

Also available in: Atom PDF