nji's profile - activity

OpenCV 3.4.10 with Intel TBB I recently updated to 3.4. (at Win7 64bit, mingw64) read the official tutorial for installi

Include paths: Changes from v. 3.2 to 3.4. I recently had to update. For a simple test app just using core and highgui

Include paths: Changes from v. 3.2 to 3.4. I recently had to update. For a simple test app just using core and highgui

I do have to understand ... not only to learn, but to be able to assess if this is a proper solution/ answer to the ques

Please don't let me die ignorant. Can you please tell me what's the effect of the both workarounds? What's their effects

Please don't let me die ignorant. Can you please tell me what's the effect of the both workarounds? What's their effects

Maybe it's because of my paranoia... but sometimes I have that suspicion, that the devs build that hurdles only to check

Thank you for your hint. But to my experience it's quite the opposite. If I (have to) do a major update of one component

Thank you for your hint. But to my experience it's quite the opposite. If I (have to) do a major update of one component

Thank you for your hint. But to my experience it's quite the opposite. If I (have to) to a major update of one component

OpenCV 3.4, build with MinGW 8.1.0 I recently updated my Code::Block version which optional comes with mingw. Also updat

OpenCV 3.4, build with MinGW 8.1.0 I recently updated my Code::Block version which optional comes with mingw. Also updat

(... while my 8 horses have been busy ... ;-)) ... ). The point is I'm still a newby to open source toolchains (coming f

Found it ... (at last!) in cmake: CMAKE_CODEBLOCKS_MAKE_ARGUMENTS

Found it ... (at last!) in cmake: CMAKE_CODEBLOCKS_MAKE_ARGUMENTS. (Could not answer myself, as not allowed as "new user

Thankyou again. Still we're misunderstanding ... I try to explain: cmake generates the makefiles (and in my case the cod

Thankyou again. Still we're misunderstanding ... I try to explain: cmake generates the makefiles (and in my case the cod

Thankyou again. Still we're misunderstanding ... I try to explain: cmake generates the makefiles (and in my case the cod

Thankyou again. Still we're misunderstanding ... I try to explain: cmake generates the makefiles (and in my case the cod

Yes, I know that. My question is HOW and where to insert the -jN-Option. As cmake builds the make files, this should be

Building opencv in parallel with mingw (using cmake-gui) Is this possible with tdm-gcc 4.9? And where do I have to set w

And one more info: Using the directshow interface I never noticed (or heard about) getting wrong frames with IMediaSeeking::SetPositions. (For files directshow can't be used from opencv as this option is not implemented ...)

Some more information. There is a (4 y/o) post at stackoverflow about it. And then ... if you have a look at opencv code (CvCapture_FFMPEG::seek(int64_t) ... you find some kind of "index acrobatics" in there. To me (being someone who just needs to USE it) it looks as if ffmpeg delivers wrong frames sometimes because of decoding issues (keyframe etc.). If that is the case it's the question who should take the responsibility: ffmpeg (to always deliver what is wanted) - or the customer (opencv) trying to correct the failure. Doing the correction on app layer (I did that) is a pretty index mess. Anybody out there?

I would like to point to. Solved. Or not solved? What is here the question?

Excuse me ... I've to ask: "nothing constant"? Do you mean that all compared frames are different? If that is the case then I think that the results of command ffmpeg are the correct ones, as they are "streamed", which seems to produce correct extractions. ... I think the question is which ffmpeg interface/ parameters opencv uses. Maybe the parameter is timestamp, not framenumber? Where are the opencv developers? ;-)

(Sorry for the late addendum - but the server seems to be sleepy so I couldn' add to the comment above). But maybe the trim parameter (with start_frame/ end_frame for exact frame extraction) doesn't quick JUMP to the position (as opencv set () does), but walks from beginning?

I tried ffmpeg command line with the trim parameter but didn't get useful results...

I can't tell for sure. But as there are many posts in the different forums concerning getting wrong frames using opencv, for me seems to be a problem of collaboration (See my quote of the opencv docs 10 comments above). And nobody takes responsibilty. To me it looks as if opencv uses ffmpeg in a somekind wrong way. As ffmpeg is the base I think an error there quite unlikely. But I'm no expert at all.

@LBerger: The problem seems to be spreaded (as there are many posts in the forums), but nobody seems to care (see my posted issue). They say opencv is about image processing and reading in is utility/ peripheral. (Like providing a car but with no functional doors). So if (!) one detects that this bug exists one has to do some kind of work-around for correct positioning. For the problem of not getting the last frames (if mispositioned too early) I don't have a solution so far at all. Very sad all this.

I recently updated my hardware and came to the idea to speed up an application of mine that analyses movie files (say: compute the differences of adjacent frames) to do parallel. The idea was to assign the file partwise to the cores/ threads, to do reading/ processing indepently and after that do the stitching (necessary because of inaccuracies). I tried that and got very disappointing speed-ups. I posted that to stackoverflow as I don't know where the cause is (os, opencv, codecs, hardware, ...) but didn't get helpful feedback.

So my try specific in this forum. As it seems a task of general interest.

Is it possible to speedup reading in/ analysing a movie file using opencv? And how do it best? (My attempt seems to have same flaw).

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?

Done. Maybe I may draw your attention to the question where this problem arose from, and where I didn't get any satifying solution for)

Excuse for the confusion. I didn't notice your change in the answer. Still ... I'm a little in doubt if it makes any sense to post an issue, as I think it is quite likely that it is not a bug in opencv but an "effect" of the "layer chain" (see quote from the doc above). The maintainers might just point to that. What do you think? Maybe we (I) should just close this thread with an answer that one should NOT rely on seeking to be always exact?

Take this (MP4 Medium 10,7 MB). With "pos-factor 50" it gives

CAP_PROP_FOURCC: avc1 0 0 0 0 -166 198 -162 144 -234 249 0 0 -204 217 0 0 -235 221 -213 204 -166 148 -217 194 -215 221 0 0 0 0

All 0 for me too then! This means it depends also on the video. And then "Reading / writing properties involves many layers. Some unexpected result might happens along this chain. Effective behaviour depends from device hardware, driver and API Backend." Seems I've to insert some "intelligent" fuzzy logic.

So you use the codecs from within ffmpeg, too? But as 64bit. Would you mind trying a second video file?

Sorry, I did a (small) mistake. When I take your new init then I get

CAP_PROP_FOURCC: avc1
-160    114
-132    149
-207    202
-181    176
-178    175
-203    248
-156    164
-126    160
-241    221
-208    239
-202    208
-196    166
-182    117
-149    147
-128    138

You get all 0s? (That's what I get with the original init positions) Maybe it's because the different compilers and me using the 32bit ffmpeg? (BTW ffmpeg with codec included)