Problem with retrieving frames from h264 video [Linux Ubuntu versus Windows 7] (Bug #3326)


Added by Steven Puttemans over 11 years ago. Updated over 9 years ago.


Status:Open Start date:2013-10-17
Priority:Normal Due date:
Assignee:Vadim Pisarevsky % Done:

0%

Category:highgui-video
Target version:2.4.10
Affected version:2.4.6 (latest release) Operating System:Windows
Difficulty: HW Platform:x64
Pull request:

Description

I have a video and a file containing xml annotations.
The video file is an infra red video feed of a car park, where I want to perform detection of persons and video.

We have a problem with the reading of the actual video file and matching the annotations.

ON WINDOWS 7 X64 OPENCV 2.4.6

When running the code supplied in attachements called 'inlezen.cpp', errors get outputted, connected to the h264 encoding. The result is that the bounding box of the first frame (green and red box overlap but ignore that part) gets printed at the extracted location that was matched with the first annotation in the file. If you look close, you can see that the actual persons is in front of the annotation.

'!error_image.PNG!'

ON LINUX UBUNTU 12.06 OPENCV 2.4.6

However, running the same code on linux, only produces the first 2 error lines as seen in the image, not the others. Result is that the bounding box matches perfectly with the person intended to encapsulate.

I am afraid this has something to do with the video itself and not with openCV, but I want to make sure nevertheless. The video can be found at this link: http://www.eavise.be/tobcat/opencv/video.avi

The annotation file is in the extras added to this post, but video was to large.

The test archive contains all functionality needed to extract the xml from the xgtf file and the inlezen.cpp file contains all the functionality used to read in the frames. You can see that there is some logic to match the correct annotations with the correct frame, but that works correctly (like illustrated on Linux).

I am just wondering why there is a difference between both systems, VideoCapture uses the same ffmpeg library right?


error_image.PNG (180.3 kB) Steven Puttemans, 2013-10-17 10:37 am

Motion_2013-04-24_1711.55_72.xgtf (62 kB) Steven Puttemans, 2013-10-17 10:37 am

test.rar (40.5 kB) Steven Puttemans, 2013-10-17 10:37 am


Associated revisions

Revision a7983866
Added by Vadim Pisarevsky over 10 years ago

Merge pull request #3326 from ilya-lavrenov:neon_canny

History

Updated by Steven Puttemans over 11 years ago

Also as an addition, the number that is printed in the output, is a check that the current frame 1157 is the same as the first annotation that contains a human, which is class 11 in the xml file.

Updated by Maria Dimashova over 11 years ago

  • Assignee set to Vadim Pisarevsky

Updated by Steven Puttemans over 11 years ago

I can add that I have tested it in x64 and x86 of the operating systems and that the conflict stays the same.
It thus must have something to do with the h264 encoding of the ffmpeg library i think...

Updated by Dmitry Retinskiy over 11 years ago

  • Status changed from New to Open
  • Target version changed from 2.4.7 to 2.4.8

Updated by Steven Puttemans over 11 years ago

I have just pulled the latest 2.4 version from GIT, still no changes, not even with the new ffmpeg library included.
Is the latest ffmpeg library provided? Of is there a possibility of building with an even more recent version?

Updated by Alexander Smorkalov about 11 years ago

  • Target version changed from 2.4.8 to 2.4.9

Updated by Alexander Smorkalov almost 11 years ago

  • Target version changed from 2.4.9 to 2.4.10

Updated by Maksim Shabunin over 9 years ago

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

Also available in: Atom PDF