Arch Linux

Description:

In python 3, using method read() on cv2.VideoCapture (opncv) object takes more time than needed.
In particular a simple loop containing only invocation of read() method retrieves frame at the rate indicated in the video container:

vs = cv2.VideoCapture("a.mp4") #a.mp4 is a video at n fps (reported in video container)
while True:
frame = vs.read()

The cycle runs at n cycles per seconds, aka the framerate of video processing sticks to the video framerate

Expected behavior: it must run as fast as possible

Packages:
* opencv 3.4.3
* gst-libav 1.14.4
* python 3.7.0

Simple script: (python 3)

import cv2
import numpy
import time
import sys

filename = sys.argv[1]

vs = cv2.VideoCapture(filename)

more = True
framecounter = 0
start_time = time.perf_counter()

while more:
framecounter += 1
frame = vs.read()
more = frame[0]

stop_time = time.perf_counter()
duration = stop_time - start_time

print("Filename: {}".format(filename))
print("Elapsed : {0:.2f} s".format(duration))
print("FPS : {0:.2f} fps".format(framecounter/duration))
print("\n")

Output:
$ python test.py test_11.mp4 && python test.py test_30.mp4 && python test.py test_59.mp4
Filename: test_11.mp4 #600x400 h256 video at 11fps
Elapsed : 29.91 s
FPS : 11.07 fps


Filename: test_30.mp4 #1080p h256 video at 29.75fps
Elapsed : 29.99 s
FPS : 29.91 fps


Filename: test_59.mp4 #1080p h256 video at 59fps
Elapsed : 8.59 s
FPS : 60.16 fps

Steps to reproduce:
Run the reported script with videos at different framerates

Note:
It seems not to be a performance issue since the framerate is almost 6x higher decoding 1080p video with respect to 600x400 video
Also this problem it is not reported with other (non-archlinux) opencv/gstreamer builds