Basic example halts partway through video

asked 2014-07-10 13:48:19 -0500

Ember gravatar image

I'm using a basic example from

as a basis for a rat-tracking program. It's working great, except for the following issue.

It runs for the first 45 seconds of the video, then gives the error "OpenCV Error: Assertion failed ((scn == 3 :: scn == 4) && (depth == CV_8U :: depth == CV_32F))" at the same frame each time. It gives this error for multiple videos, at slightly different points in each video. I tried converting the video to an avi format- it stops at the same point. There is nothing visually wrong with the video (I can watch it fine on normal video players). I've tried googling the problem, to no avail. Any suggestions would be appreciated.

import numpy as np
import cv2

cam = cv2.VideoCapture('Video2.wmv')

    # Capture frame-by-frame
    ret, frame =
    print frames
    # Our operations on the frame come here
    gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY)

    # Display the resulting frame
    if cv2.waitKey(1) & 0xFF == ord('q'):

print frames
# When everything done, release the capture
edit retag flag offensive close merge delete


i got no idea, how an arbitrary single frame from a video could be invalid, but let's play paranoid, insert something similar to :

 print ret, np.shape(frame)

before the cv2.cvtColor(). somehow it does not like it's dinner ;)

berak gravatar imageberak ( 2014-07-10 14:04:28 -0500 )edit

Hm. Before every previous frame, it prints "True (720, 1280, 3)". But for the error-causing frame it prints "False ()". ... how on earth does a single frame become invalid? And how do I remove it?

Ember gravatar imageEmber ( 2014-07-10 15:20:11 -0500 )edit

honestly, no idea, how a single invalid frame can happen in a video (never seen that before).

but the remedy is quite simple:

if  ret: 
    gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY)

    # Display the resulting frame

(you definitely don't want to bailout before the cv2.waitKey(1) call, else you don't release the capture properly)

berak gravatar imageberak ( 2014-07-10 15:31:56 -0500 )edit

Ugg. I tried several variations on that. It freezes on the current frame in the video, and eventually crashes python. I assume that may mean that all subsequent frames are invalid as well? How can that be if they play properly in a video player?

Ember gravatar imageEmber ( 2014-07-10 15:43:27 -0500 )edit

again, the main cause is: your video file is broken.

berak gravatar imageberak ( 2014-07-10 15:46:42 -0500 )edit

But it has the same problem on multiple videos. Argh. I suppose I'll try taking video again tomorrow and see if that has any effect. Thanks for the suggestions :)

Ember gravatar imageEmber ( 2014-07-10 15:48:26 -0500 )edit

just as a sidenote: the code from is meant to be used with opencv3.0, not the current 2.4.9.

abid did a nice job there, imho, but there might be a lot of slight diffs between your current cv2 version and that.

(your current example does not suffer from that by sheer luck, just saying ..)

((and again, 3.0 is long overdue...;))

berak gravatar imageberak ( 2014-07-10 15:55:04 -0500 )edit

Okay, so I did actually manage to get a couple of other test videos today. Every single one has the same problem. Something like 1/3 of the way through each video (very consistently 1/3 regardless of length) I have this same problem. When I just run the program on the camera feed, it works fine. (The camera is a toshiba webcam.) I tried recording directly with python (generating an avi file with videoWriter) and that makes a video just fine. But when I apply this program to that video, it STILL breaks. I don't know what else to try.

Ember gravatar imageEmber ( 2014-07-10 16:41:49 -0500 )edit

waa, that's bad. no idea, unfortunately.

berak gravatar imageberak ( 2014-07-10 16:51:21 -0500 )edit

probably still an internal python wrapper problem, but without a deep knowledge of the python wrapping it won't be easy to provide an off the shelf solution I am afraid...

StevenPuttemans gravatar imageStevenPuttemans ( 2014-07-11 07:03:14 -0500 )edit