avformat_find_stream_info was introduced in Libav avformat 53.3,
but it was only merged to FFmpeg in avformat 53.6.
In Libav avformat 53.3-53.5 av_find_stream_info is not removed
(only deprecated), so this shouldn't break building with that.
Searching in directory names can yield confusing results; e.g. if
the input is "jpeg2000/image1.jp2", it will infer the pattern
"jpeg%04d/image1.jp2", which is likely not what the user intended.
If the user really desires for the variable part to be in the
directory name, it can always use an explicit pattern.
Our prebuilt FFmpeg Windows binaries don't have PNG support enabled
(because that requires zlib), so that makes a PNG image a bad choice
for this test.
When FFmpeg doesn't support PNG, VideoCapture falls back to the
"image sequence" implementation, which doesn't work for single images.
Previously, VideoCapture::retrieve would return a Mat that referenced
the internal IplImage. Since the latter is rewritten every time a
frame is captured, it means that if the user captures two frames in a row,
the first frame would reference nothing. Similar if a user captures a frame,
then destroys the VideoCapture instance.
Note that the other branch of the if isn't affected, since flip allocates
a new Mat.
From commit dd74a851, to be exact. Now cap_ffmpeg.cpp should actually
build if HAVE_FFMPEG is true.
Also modified some gpu sources in a similar manner.
libpng 1.5+ recommends a call to png_set_interlace_handling() if you use
png_read_update_info and png_read_image. It will generate a warning
without it.
OpenCV's automatic builds don't care if you store an unsigned int into
an int, but they don't want you to compare signed with unsigned. Does
that make sense?
cap_qtkit does not work when the capture is run outside of the main
thread.
If the capture is launched in a separate thread, then [NSRunLoop
currentRunLoop] is not the same as in the main thread, and has no timer.
see
https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/F
oundation/Classes/nsrunloop_Class/Reference/Reference.html
"If no input sources or timers are attached to the run loop, this
method exits immediately"
Using usleep() (which I previously proposed, and was reverted) is not a
good alternative, because it may block the GUI.
Here is the new proposed solution:
- create a dummy timer so that runUntilDate does not exit immediately
- simplify the loop by using runUntilDate instead of runMode:beforeDate
- fix potential memory leaks (pointed out by Xcode's static analysis)
- fix init to follow Objective-C guidelines
- fax warnings about conversions from size_t to int