Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

VideoCapture::set (CAP_PROP_POS_FRAMES, frameNumber) not exact in opencv 3.2 with ffmpeg?

For an application (Win7/ mingw) that analyses movie files I divide the reading-in to the cores. When trying to jump to the beginning of the parts with

VideoCapture::set (CAP_PROP_POS_FRAMES, frameNumber);

and then

capt >> frame;

I do not get frame with number frameNumber but some frames before (the exact value depends on the movie format). Also the first two calls of

capt >> frame;

return the same frame.

But

VideoCapture::set (CAP_PROP_POS_FRAMES, frameNumber);

and then

ret = VideoCapture::get (CAP_PROP_POS_FRAMES);

lets frameNumber == ret

There are many threads about this issue already. Some say that in newer versions of opencv that "bug" is gone.

Other say that it's about the keyframes in the video stream that would make ffmpeg seek to the first keyframe AFTER the desired position.

Has somebody up-to-date information what happens here and how to do (this quite common task) please?

VideoCapture::set (CAP_PROP_POS_FRAMES, frameNumber) not exact in opencv 3.2 with ffmpeg?

For an application (Win7/ mingw) that analyses movie files I divide the reading-in reading and processing to the cores. When trying to jump to the beginning of the parts with

VideoCapture::set (CAP_PROP_POS_FRAMES, frameNumber);

and then

capt >> frame;

I do not get frame with number frameNumber but some frames before (the exact value depends on the movie format). Also the first two calls of

capt >> frame;

return the same frame.

But

VideoCapture::set (CAP_PROP_POS_FRAMES, frameNumber);

and then

ret = VideoCapture::get (CAP_PROP_POS_FRAMES);

lets frameNumber == ret

There are many threads about this issue already. Some say that in newer versions of opencv that "bug" is gone.

Other say that it's about the keyframes in the video stream that would make ffmpeg seek to the first keyframe AFTER the desired position.

Has somebody up-to-date information what happens here and how to do (this quite common task) please?

VideoCapture::set (CAP_PROP_POS_FRAMES, frameNumber) not exact in opencv 3.2 with ffmpeg?

For an application (Win7/ mingw) that analyses movie files I divide the reading and processing to the cores. When trying to jump to the beginning of the parts with

VideoCapture::set (CAP_PROP_POS_FRAMES, frameNumber);

and then

capt >> frame;

I do not get frame with number frameNumber but some frames before (the exact value depends on the movie format). Also the first two calls of

capt >> frame;

return the same frame.

Butformat).

Although

VideoCapture::set (CAP_PROP_POS_FRAMES, frameNumber);

and then

ret = VideoCapture::get (CAP_PROP_POS_FRAMES);

lets frameNumber == ret

There are many threads about this issue already. Some say that in newer versions of opencv that "bug" is gone.

Other say that it's about the keyframes in the video stream that would make ffmpeg seek to the first keyframe AFTER the desired position.

Has somebody up-to-date information what happens here and how to do (this quite common task) common) task please?

VideoCapture::set (CAP_PROP_POS_FRAMES, frameNumber) not exact in opencv 3.2 with ffmpeg?

For an application (Win7/ mingw) that analyses movie files I divide the reading and processing to the cores. When trying to jump to the beginning of the parts with

VideoCapture::set (CAP_PROP_POS_FRAMES, frameNumber);

and then

capt >> frame;

I do not get frame with number frameNumber but some frames before (the exact value depends on the movie format).

Although

VideoCapture::set (CAP_PROP_POS_FRAMES, frameNumber);

and then

ret = VideoCapture::get (CAP_PROP_POS_FRAMES);

lets frameNumber == ret

[Edit: This makes it even worse. As if you want to take into account that you don't get what you want always: For example you want to seek close to the end of the stream (say 10 elements before) and do want to take into account that you maybe get frame k-5 if you request frame k, and by this request the last 15 consecutive frames, then get() will return 0 for the last 5 as "it" thinks it is at the end already!]

There are many threads about this issue already. Some say that in newer versions of opencv that "bug" is gone.

Other say that it's about the keyframes in the video stream that would make ffmpeg seek to the first keyframe AFTER the desired position.

Has somebody up-to-date information what happens here and how to do (this quite common) task please?