Repository: opencv
Issue: Problem with retrieving frames from h264 video [Linux Ubuntu versus Windows 7]
Labels: bug,auto-transferred,priority: normal,category: videoio,affected: 2.4

Transferred from http://code.opencv.org/issues/3326

```
|| Steven Puttemans on 2013-10-17 08:37
|| Priority: Normal
|| Affected: 2.4.6 (latest release)
|| Category: highgui-video
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x64 / Windows
```
## Problem with retrieving frames from h264 video [Linux Ubuntu versus Windows 7]

```
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?
```
## History
##### Steven Puttemans on 2013-10-17 08:39

```
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.
```
##### Maria Dimashova on 2013-10-17 09:11

```
-   Assignee set to Vadim Pisarevsky
```
##### Steven Puttemans on 2013-10-18 12:42

```
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...
```
##### Dmitry Retinskiy on 2013-10-28 17:02

```
-   Target version changed from 2.4.7 to 2.4.8
-   Status changed from New to Open
```
##### Steven Puttemans on 2013-10-30 09:25

```
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?
```
##### Alexander Smorkalov on 2013-12-30 10:38

```
-   Target version changed from 2.4.8 to 2.4.9
```
##### Alexander Smorkalov on 2014-04-30 19:05

```
-   Target version changed from 2.4.9 to 2.4.10
```