# cv::VideoCapture.isOpen() returns TRUE even on some errors (bug?)

**URL:** <https://forum.opencv.org/t/cv-videocapture-isopen-returns-true-even-on-some-errors-bug/24512>\
**Category:** C++\
**Tags:** videoio\
**Created:** [May 19, 2026, 3:36pm UTC](https://forum.opencv.org/t/cv-videocapture-isopen-returns-true-even-on-some-errors-bug/24512 "2026-05-19T15:36:51Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![dave-007](https://avatars.discourse-cdn.com/v4/letter/d/0ea827/32.png) [@dave-007](https://forum.opencv.org/u/dave-007)\
**Post date:** [May 19, 2026, 3:36pm UTC](https://forum.opencv.org/t/cv-videocapture-isopen-returns-true-even-on-some-errors-bug/24512/1 "2026-05-19T15:36:51Z")

</div>

i’m very new to opencv, so i don’t know if this is expected behaviour or not (but it’s certainly not intuitive…). it seems that when trying to read an MP4 video, even though openh264 returns an error (and emits it to the console), OpenCV says everything is okay. in other words, openh264 can’t decode the frames, `cv::VideoCapture.isOpen()` nevertheless returns `true`.

**code snippet :**

```auto
VideoCapture cap(argv[1]);
if (cap.isOpened()) {
    cout << argv[1] << " was opened correctly!\n";
    cap.release();
} else {
    cerr << argv[1] << ": can't open video for reading\n";
}

```

**output :**

```auto
[libopenh264 @ 0x5c35c0] DecodeFrame failed
danse.mp4 was opened correctly!

```

additionally, obviously continuing to try to read the file after libopenh264 returns the error gives no results.

shouldn’t `VideoCapture.isOpen()` return an error condition?

---

<div class="post-metadata">

**Author:** ![crackwitz](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opencv.org/crackwitz/32/14_2.png) [@crackwitz](https://forum.opencv.org/u/crackwitz)\
**Post date:** [May 19, 2026, 4:15pm UTC](https://forum.opencv.org/t/cv-videocapture-isopen-returns-true-even-on-some-errors-bug/24512/2 "2026-05-19T16:15:38Z")

</div>

yeah it’s an old and unloved API, with plenty of warts.

in this case though, ffmpeg is to blame, not OpenCV.

someone built OpenCV against a _bare_ ffmpeg, which doesn’t come with the usual H.264 codecs, but only `libopenh264` support. that is probably due to IP laws.

you could see about building OpenCV yourself, such that it gets a full-featured ffmpeg (all the H.264 usual codecs), not just one with `libopenh264`. then, chances are better that it can actually read your video file.

if you can, I’d recommend using ffmpeg APIs directly, and dropping `VideoCapture`. ffmpeg is a C API, but it’s so much nicer than OpenCV’s `VideoCapture`.

* * *

I would call that a bug, and you should file it (unless it’s already filed). if you decide to do that, please prepare a video file that reproduces the issue.

OpenCV keeps a set of video files as test vectors. if any of _those_ reproduces the problem, you don’t even have to upload anything into the issue: [opencv\_extra/testdata/highgui/video at 4.x · opencv/opencv\_extra · GitHub](https://github.com/opencv/opencv_extra/tree/4.x/testdata/highgui/video)

you should also make sure that the issue is reproducible on latest OpenCV release (4.13 at this time).