Support for the custom sink is extended to non-WinRT not for compatibility as Windows Vista client is a minimum regardless, but because it offers more flexibility, could be faster and is able to be used as an optionally different code path during sink creation based on a future configuration parameter.
My discussion and proposal to finish this change:
Devices are so easily enumerated through WinRT Windows.Devices namespace that wrapping the calls in a library is quite a chore for little benefit though to get the various modes and formats could still be a worthwhile project. For now conditional compilation to remove videodevices and any offending non-video file related activity in videodevice. In my opinion, this is a different , far less fundamental and important change which can possibly be done as a future project and also much more easily implemented in C++/CX.
ImageGrabber has the IMFSampleGrabberSinkCallback replaced with a base class (SharedSampleGrabber) which also be is base class for ImageGrabberRT. This change is necessary as the custom sink does not require a thread to pump events which is done through MediaCapture already. IMFSampleGrabberSinkCallback is the common element between both models and that piece can be shared. Initializing the new ImageGrabberRT is as simple as passing an already initialized MediaCapture object and any video format/encoding parameters.
The concurrency event is necessary to wait for completion and is the way the underlying, IAsyncAction wrappers in the task library work as well. Native WIN32 event objects would be an option if HAVE_CONCURRENCY is not defined. I could even imagine doing it with sleep/thread yield and InterlockedCompareExchange yet I am not enthusiastic about that approach either. Since there is a specific compiler HAVE_ for concurrency, I do not like pulling it in though I think for WinRT it is safe to say we will always have it available though should probably conditionally compile with the Interlocked option as WIN32 events would require HAVE_WIN32.
It looks like C++/CX cannot be used for the IMediaExtension sink (which should not be a problem) as using COM objects requires WRL and though deriving from IMediaExtension can be done, there is little purpose without COM. Objects from C++/CX can be swapped to interact with objects from native C++ as Inspectable* can reinterpret_cast to the ref object IInspectable^ and vice-versa. A solution to the COM class with C++/CX would be great so we could have dual support. Also without #define for every WRL object in use, the code will get quite muddy given that the */^ would need to be ifdef'd everywhere.
Update cap_msmf.cpp
Fixed bugs and completed the change. I believe the new classes need to be moved to a header file as the file has become to large and more classes need to be added for handling all the asynchronous problems (one wrapping IAsyncAction in a task and another for making a task out of IAsyncAction). Unfortunately, blocking on the UI thread is not an option in WinRT so a synchronous architecture is considered "illegal" by Microsoft's standards even if implementable (C++/CX ppltasks library throws errors if you try it). Worse, either by design or a bug in the MF MediaCapture class with Custom Sinks causes a crash if stop/start previewing without reinitializing (spPreferredPreviewMediaType is fatally nulled). After decompiling Windows.Media.dll, I worked around this in my own projects by using an activate-able custom sink ID which strangely assigns 1 to this pointer allowing it to be reinitialized in what can only be described as a hack by Microsoft. This would add additional overhead to the project to implement especially for static libraries as it requires IDL/DLL exporting followed by manifest declaration. Better to document that it is not supported.
Furthermore, an additional class for IMFAttributes should be implemented to make clean architecture for passing around attributes as opposed to directly calling non-COM interface calls on the objects and making use of SetProperties which would also be a set up for an object that uses the RuntimeClass activation ID.
The remaining changes are not difficult and will be complete soon along with debug tracing messages.
Update and rename cap_msmf.h to cap_msmf.hpp
Successful test - samples are grabbed
Library updated and cleaned up with comments, marshaling, exceptions and linker settings
Fixed trailing whitespace
VS 2013 support and cleanup consistency plus C++/CX new object fixed
VS 2013 Update 2 library bug fix integrated
Various minor cleanup
Create agile_wrl.h
a-wi's changes integrated
Update cap_msmf.hpp
Update cap_msmf.cpp
Regression test fixes and simplifications
Support for the custom sink is extended to non-WinRT not for compatibility as Windows Vista client is a minimum regardless, but because it offers more flexibility, could be faster and is able to be used as an optionally different code path during sink creation based on a future configuration parameter.
My discussion and proposal to finish this change:
Devices are so easily enumerated through WinRT Windows.Devices namespace that wrapping the calls in a library is quite a chore for little benefit though to get the various modes and formats could still be a worthwhile project. For now conditional compilation to remove videodevices and any offending non-video file related activity in videodevice. In my opinion, this is a different , far less fundamental and important change which can possibly be done as a future project and also much more easily implemented in C++/CX.
ImageGrabber has the IMFSampleGrabberSinkCallback replaced with a base class (SharedSampleGrabber) which also be is base class for ImageGrabberRT. This change is necessary as the custom sink does not require a thread to pump events which is done through MediaCapture already. IMFSampleGrabberSinkCallback is the common element between both models and that piece can be shared. Initializing the new ImageGrabberRT is as simple as passing an already initialized MediaCapture object and any video format/encoding parameters.
The concurrency event is necessary to wait for completion and is the way the underlying, IAsyncAction wrappers in the task library work as well. Native WIN32 event objects would be an option if HAVE_CONCURRENCY is not defined. I could even imagine doing it with sleep/thread yield and InterlockedCompareExchange yet I am not enthusiastic about that approach either. Since there is a specific compiler HAVE_ for concurrency, I do not like pulling it in though I think for WinRT it is safe to say we will always have it available though should probably conditionally compile with the Interlocked option as WIN32 events would require HAVE_WIN32.
It looks like C++/CX cannot be used for the IMediaExtension sink (which should not be a problem) as using COM objects requires WRL and though deriving from IMediaExtension can be done, there is little purpose without COM. Objects from C++/CX can be swapped to interact with objects from native C++ as Inspectable* can reinterpret_cast to the ref object IInspectable^ and vice-versa. A solution to the COM class with C++/CX would be great so we could have dual support. Also without #define for every WRL object in use, the code will get quite muddy given that the */^ would need to be ifdef'd everywhere.
Fixed bugs and completed the change. I believe the new classes need to be moved to a header file as the file has become to large and more classes need to be added for handling all the asynchronous problems (one wrapping IAsyncAction in a task and another for making a task out of IAsyncAction). Unfortunately, blocking on the UI thread is not an option in WinRT so a synchronous architecture is considered "illegal" by Microsoft's standards even if implementable (C++/CX ppltasks library throws errors if you try it). Worse, either by design or a bug in the MF MediaCapture class with Custom Sinks causes a crash if stop/start previewing without reinitializing (spPreferredPreviewMediaType is fatally nulled). After decompiling Windows.Media.dll, I worked around this in my own projects by using an activate-able custom sink ID which strangely assigns 1 to this pointer allowing it to be reinitialized in what can only be described as a hack by Microsoft. This would add additional overhead to the project to implement especially for static libraries as it requires IDL/DLL exporting followed by manifest declaration. Better to document that it is not supported.
Furthermore, an additional class for IMFAttributes should be implemented to make clean architecture for passing around attributes as opposed to directly calling non-COM interface calls on the objects and making use of SetProperties which would also be a set up for an object that uses the RuntimeClass activation ID.
The remaining changes are not difficult and will be complete soon along with debug tracing messages.
Update and rename cap_msmf.h to cap_msmf.hpp
Successful test - samples are grabbed
Library updated and cleaned up with comments, marshaling, exceptions and linker settings
Fixed trailing whitespace
VS 2013 support and cleanup consistency plus C++/CX new object fixed
Conflicts:
modules/highgui/src/cap_msmf.cpp
modules/highgui/src/cap_msmf.hpp
modules/highgui/src/ppltasks_winrt.h
Fix merge conflicts
VS 2013 Update 2 library bug fix integrated
a-wi's changed integrated
The documentation states, that a NULL or an empty window name can be used
to refer to the control panel. But the string parameters of the C++ frontend
methods cannot be NULL and converting an empty string to a const char* by
c_str() doesn't produce a NULL pointer, but an empty string. Unfortunately,
the const char* pointer is just passed on to the standard C functions in
the QT backend, which doesn't check for the empty string case.
There are two places where the empty string check could have been introduced:
inside the frontend or inside the backend. As long as the documentation only
mentions this as a special case for the QT backend, the best place seems to
be there.
Fixed a memory leak in cap_dshow.cpp in videoInput::setVideoSettingCamera(). The leak was caused by not releasing an IBaseFilter object created in a call to getDevice(). Tho object is now properly released.
CvCapture_GStreamer::retrieveFrame assumes that RGB videos are 24BPP.
This is not necesarily the case, unless we explicitly tell GStreamer
that we want 24BPP RGB streams.
Adding bpp=(int)24 to the appsink caps.
Implement missing features in CvCaptureCAM_VFW class.
Implemented missing CvCaptureCAM_VFW::setProperty() member function (handling CV_CAP_PROP_FRAME_WIDTH, CV_CAP_PROP_FRAME_HEIGHT, CV_CAP_PROP_FPS properties).
Extended CvCaptureCAM_VFW::setProperty()/getProperty() functions to handle also CV_CAP_PROP_FPS property.
Minor refactoring of CvCaptureCAM_VFW class.
Add support for WinRT in the MF capture framework by removing the disallowed calls to enumerate devices and create a sample grabber sink and adding framework for the MediaCapture interface and a custom sink which interfaces with the sample grabber callback interface. The change requires discussion for making it completely functional as redundancy is required given that if the source is a video file, the old code pathways must be used. Otherwise all IMFMediaSession, IMFMediaSource, and IMFActivate code must use a MediaCapture code path and all sink code must use the CMediaSink custom sink.
Support for the custom sink is extended to non-WinRT not for compatibility as Windows Vista client is a minimum regardless, but because it offers more flexibility, could be faster and is able to be used as an optionally different code path during sink creation based on a future configuration parameter.
My discussion and proposal to finish this change:
Devices are so easily enumerated through WinRT Windows.Devices namespace that wrapping the calls in a library is quite a chore for little benefit though to get the various modes and formats could still be a worthwhile project. For now conditional compilation to remove videodevices and any offending non-video file related activity in videodevice. In my opinion, this is a different , far less fundamental and important change which can possibly be done as a future project and also much more easily implemented in C++/CX.
ImageGrabber has the IMFSampleGrabberSinkCallback replaced with a base class (SharedSampleGrabber) which also be is base class for ImageGrabberRT. This change is necessary as the custom sink does not require a thread to pump events which is done through MediaCapture already. IMFSampleGrabberSinkCallback is the common element between both models and that piece can be shared. Initializing the new ImageGrabberRT is as simple as passing an already initialized MediaCapture object and any video format/encoding parameters.
The concurrency event is necessary to wait for completion and is the way the underlying, IAsyncAction wrappers in the task library work as well. Native WIN32 event objects would be an option if HAVE_CONCURRENCY is not defined. I could even imagine doing it with sleep/thread yield and InterlockedCompareExchange yet I am not enthusiastic about that approach either. Since there is a specific compiler HAVE_ for concurrency, I do not like pulling it in though I think for WinRT it is safe to say we will always have it available though should probably conditionally compile with the Interlocked option as WIN32 events would require HAVE_WIN32.
It looks like C++/CX cannot be used for the IMediaExtension sink (which should not be a problem) as using COM objects requires WRL and though deriving from IMediaExtension can be done, there is little purpose without COM. Objects from C++/CX can be swapped to interact with objects from native C++ as Inspectable* can reinterpret_cast to the ref object IInspectable^ and vice-versa. A solution to the COM class with C++/CX would be great so we could have dual support. Also without #define for every WRL object in use, the code will get quite muddy given that the */^ would need to be ifdef'd everywhere.
Update cap_msmf.cpp
Fixed bugs and completed the change. I believe the new classes need to be moved to a header file as the file has become to large and more classes need to be added for handling all the asynchronous problems (one wrapping IAsyncAction in a task and another for making a task out of IAsyncAction). Unfortunately, blocking on the UI thread is not an option in WinRT so a synchronous architecture is considered "illegal" by Microsoft's standards even if implementable (C++/CX ppltasks library throws errors if you try it). Worse, either by design or a bug in the MF MediaCapture class with Custom Sinks causes a crash if stop/start previewing without reinitializing (spPreferredPreviewMediaType is fatally nulled). After decompiling Windows.Media.dll, I worked around this in my own projects by using an activate-able custom sink ID which strangely assigns 1 to this pointer allowing it to be reinitialized in what can only be described as a hack by Microsoft. This would add additional overhead to the project to implement especially for static libraries as it requires IDL/DLL exporting followed by manifest declaration. Better to document that it is not supported.
Furthermore, an additional class for IMFAttributes should be implemented to make clean architecture for passing around attributes as opposed to directly calling non-COM interface calls on the objects and making use of SetProperties which would also be a set up for an object that uses the RuntimeClass activation ID.
The remaining changes are not difficult and will be complete soon along with debug tracing messages.
Update and rename cap_msmf.h to cap_msmf.hpp
Update cap_msmf.cpp
Successful test - samples are grabbed
Update ppltasks_winrt.h
Library updated and cleaned up with comments, marshaling, exceptions and linker settings
Fixed trailing whitespace
Support VS 2013 and consistency cleanup and C++/CX object creation fixed
The linux buildbots have started to fail compilation due to not
finding the gtk headers. The quotes have been changed to angle brackets
to indicate to the compiler that these are system includes.
specific code. As a result of this, HAVE_GTK3 no longer needs to be
exposed.
The use of HAVE_GTK, and HAVE_ GTK3 have been changed to mirror the
method used by HAVE_QT and HAVE_QT5.
On branch gtk3
Changes to be committed:
modified: CMakeLists.txt
modified: cmake/OpenCVFindLibsGUI.cmake
modified: cmake/templates/cvconfig.h.in
modified: modules/highgui/src/window.cpp
modified: modules/highgui/src/window_gtk.cpp
Fixed constant value for focus mode FOCUS_MODE_CONTINUES_PHOTO;
Add setters and getters for exposure lock and white balance lock flags;
Excluded camera restart for all setters except frame size.
Add support for WinRT in the MF capture framework by removing the disallowed calls to enumerate devices and create a sample grabber sink and adding framework for the MediaCapture interface and a custom sink which interfaces with the sample grabber callback interface. The change requires discussion for making it completely functional as redundancy is required given that if the source is a video file, the old code pathways must be used. Otherwise all IMFMediaSession, IMFMediaSource, and IMFActivate code must use a MediaCapture code path and all sink code must use the CMediaSink custom sink.
Support for the custom sink is extended to non-WinRT not for compatibility as Windows Vista client is a minimum regardless, but because it offers more flexibility, could be faster and is able to be used as an optionally different code path during sink creation based on a future configuration parameter.
My discussion and proposal to finish this change:
Devices are so easily enumerated through WinRT Windows.Devices namespace that wrapping the calls in a library is quite a chore for little benefit though to get the various modes and formats could still be a worthwhile project. For now conditional compilation to remove videodevices and any offending non-video file related activity in videodevice. In my opinion, this is a different , far less fundamental and important change which can possibly be done as a future project and also much more easily implemented in C++/CX.
ImageGrabber has the IMFSampleGrabberSinkCallback replaced with a base class (SharedSampleGrabber) which also be is base class for ImageGrabberRT. This change is necessary as the custom sink does not require a thread to pump events which is done through MediaCapture already. IMFSampleGrabberSinkCallback is the common element between both models and that piece can be shared. Initializing the new ImageGrabberRT is as simple as passing an already initialized MediaCapture object and any video format/encoding parameters.
The concurrency event is necessary to wait for completion and is the way the underlying, IAsyncAction wrappers in the task library work as well. Native WIN32 event objects would be an option if HAVE_CONCURRENCY is not defined. I could even imagine doing it with sleep/thread yield and InterlockedCompareExchange yet I am not enthusiastic about that approach either. Since there is a specific compiler HAVE_ for concurrency, I do not like pulling it in though I think for WinRT it is safe to say we will always have it available though should probably conditionally compile with the Interlocked option as WIN32 events would require HAVE_WIN32.
It looks like C++/CX cannot be used for the IMediaExtension sink (which should not be a problem) as using COM objects requires WRL and though deriving from IMediaExtension can be done, there is little purpose without COM. Objects from C++/CX can be swapped to interact with objects from native C++ as Inspectable* can reinterpret_cast to the ref object IInspectable^ and vice-versa. A solution to the COM class with C++/CX would be great so we could have dual support. Also without #define for every WRL object in use, the code will get quite muddy given that the */^ would need to be ifdef'd everywhere.
Update cap_msmf.cpp
Fixed bugs and completed the change. I believe the new classes need to be moved to a header file as the file has become to large and more classes need to be added for handling all the asynchronous problems (one wrapping IAsyncAction in a task and another for making a task out of IAsyncAction). Unfortunately, blocking on the UI thread is not an option in WinRT so a synchronous architecture is considered "illegal" by Microsoft's standards even if implementable (C++/CX ppltasks library throws errors if you try it). Worse, either by design or a bug in the MF MediaCapture class with Custom Sinks causes a crash if stop/start previewing without reinitializing (spPreferredPreviewMediaType is fatally nulled). After decompiling Windows.Media.dll, I worked around this in my own projects by using an activate-able custom sink ID which strangely assigns 1 to this pointer allowing it to be reinitialized in what can only be described as a hack by Microsoft. This would add additional overhead to the project to implement especially for static libraries as it requires IDL/DLL exporting followed by manifest declaration. Better to document that it is not supported.
Furthermore, an additional class for IMFAttributes should be implemented to make clean architecture for passing around attributes as opposed to directly calling non-COM interface calls on the objects and making use of SetProperties which would also be a set up for an object that uses the RuntimeClass activation ID.
The remaining changes are not difficult and will be complete soon along with debug tracing messages.
Update cap_msmf.cpp
Create cap_msmf.h
Update cap_msmf.cpp
Update cap_msmf.h
Update cap_msmf.cpp
Update cap_msmf.h
Update and rename cap_msmf.h to cap_msmf.hpp
Update cap_msmf.cpp
Update CMakeLists.txt
Update cap_msmf.hpp
Update cap_msmf.cpp
Update cap_msmf.cpp
Update cap_msmf.cpp
Update cap_msmf.hpp
Update cap_msmf.hpp
Update cap_msmf.cpp
Successful test - samples are grabbed
Update cap_msmf.cpp
Update cap_msmf.hpp
Update cap_msmf.cpp
Update cap_msmf.hpp
Update cap_msmf.hpp
Update cap_msmf.cpp
Update cap_msmf.hpp
Update cap_msmf.cpp
Update cap_msmf.hpp
Update cap_msmf.cpp
Update cap_msmf.hpp
Create ppltasks_winrt.h
Update cap_msmf.hpp
Update cap_msmf.hpp
Update cap_msmf.cpp
Update ppltasks_winrt.h
Library updated and cleaned up with comments, marshaling, exceptions and linker settings
Update ppltasks_winrt.h
Fixed trailing whitespace
Use correct integer types for arguments to TIFFGetField to avoid corruption
of values and failed loads of TIFF file when using cv::imread().
Added test where both big and little endian TIFF files are read using imread().
Fixed build of 3rdparty libtiff on big endian hosts.
Reduced memory required during decode_tile16384x16384 test by not converting
large grayscale test image to color image during read.
To be used in the mouse callback like this:
if (CV_EVENT_MOUSEWHEEL == CV_GET_MOUSEWHEEL_EVENT(event))
{
int delta= CV_GET_WHEEL_DELTA(event);
// use delta...
}
Also deleted miscellaneous remaining multimon cruft.
Deleted #include <winuser.h>, because <windows.h> includes it
already.
This should have a nice side effect of preventing us from
accidentally using any Windows API that's too new.
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.
- crosses initializations in "cap_ximea.cpp" (which also contained some awfull "goto" instructions)
- the "CMAKE_CL_64" variable is not initialized when using mingw
PR#1039 modified to be able to merge on branch 2.4
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.
The gtk3 resize functions fail to shrink the window after it has been
resized. This edit changes this and allows the window to be shrunk
back to its original size.
This edit also cleans up the draw/expose functions.
A new option WITH_GTK3 has been added to the cmake configure system to enable compilation under Gtk version 3.The flag HAVE_GTK3 is also introduced to select the new Gtk3 code in the source files. (Gtk2 is disbled when Gtk3 is selected).
window_gtk.cpp has been modified to remove obsolete (and deleted from libgtk 3) and introduce new Gtk3 code in its place when compiled for Gtk3.
To compile for Gtk2, disable WITH_GTK3 in cmake. To build for Gtk3 both WITH_GTK and WITH_GTK3 must be selected.
This update replaces depreciated Gtk1.x symbols with Gtk2.x symbols in
preparation for adding Gtk3 support. These edits aim to be fully
compatible with Gtk2.x, allowing backward compatibility.
The following symbols have been replaced in this commit:
Gtk symbols that have been moved to the Gdk library:
- GtkType -> Gtype
- GTK_CHECK_CAST -> G_TYPE_CHECK_INSTANCE_CAST
- GTK_CHECK_TYPE -> G_TYPE_CHECK_INSTANCE_TYPE
- gtk_signal_connect -> g_signal_connect
- GTK_SIGNAL_FUNC -> G_CALLBACK
- gtk_type_class -> g_type_class_peek
- gtk_type_new-> g_object_new
- GtkTypeInfo -> GtypeInfo (Not required for
g_type_register_static_simple)
- gtk_type_unique -> g_type_register_static_simple
- gdk_draw_image_rgb -> replaced by gdk_cairo_source_pixbuf
NB: This requires porting to use cairo contexts and GdkPixbufs.
The following gtk symbols are changed for their modern equivalent:
- GTK_WIDGET_REALIZED -> gtk_widget_get_realized
- GTK_OBJECT_FLAGS -> gtk_widget_set_realized
Symbols without replacement:
- gtk_range_set_update_policy -> No replacement; as default policy is
set to continuous we can delete this line.
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
VideoCapture didn't call release method and just ignored the new capture sources.
OpenCV documentation:
bool VideoCapture::open(const string& filename);
bool VideoCapture::open(int device);
The methods first call VideoCapture::release() to close the already opened file or camera.
I've left HAVE_LIBPTHREAD as a CMake variable, since TBB's build depends on it.
Some macros in internal.hpp depended on HAVE_ALLOCA_H, but they were, in turn,
unused, so I've just deleted them all.
VideoCapture didn't call release method and just ignored the new capture sources.
OpenCV documentation:
bool VideoCapture::open(const string& filename);
bool VideoCapture::open(int device);
The methods first call VideoCapture::release() to close the already opened file or camera.
[NSRunLoop currentRunLoop] is not the same as in the main thread.
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"
The old code caused grabFrame() to return immediately if the capture
was not done in the main thread.
This code works correctly, even in secondary threads, provided that all
capture functions are called in the *same* thread
Video i/o tests enabled for media foundation;
Negative stride support added to VideoCapture;
Error handling improved, dead lock in case of playback error fixed;
Some code refacotring done.
Original pull requests:
#996 from jet47:gpu-nvcuvid-libraries
#995 from jet47:fix-bug-2985
#999 from snosov1:unreliable-results-fix
#1005 from alekcac:doc_fix
#1004 from jet47:fix-bug-3068
#987 from jet47:bug-3085-fix
#969 from pengx17:2.4_binary_cache
#929 from dominikrose:mingw-libdc1394-2-windows
#1000 from ivan-korolev:fix_sift_bug_2892
#1001 from ivan-korolev:fix_stitching_bug_2405
#998 from asmorkalov:android_cmake_mips_fix
#993 from ivan-korolev:fix_videostab_bug_3023
#988 from snosov1:3071-fix
#986 from pengx17:2.4_initiated_context
#982 from pengx17:2.4_fix_two_bugs
#981 from SeninAndrew:ximea_camera_support_fix
#991 from asmorkalov:android_javadoc_fix
#972 from jet47:mog2-params-bug-2168
#980 from SpecLad:include-config
#973 from pengx17:2.4_oclclahe
#903 from aks2:2.4
#968 from asmorkalov:android_na_cproj_fix
#971 from SpecLad:matchers-ctor
#970 from asmorkalov:dshow_valid_check_fix
#965 from apavlenko:fix_java_empty_mats
Conflicts:
cmake/OpenCVModule.cmake
modules/core/src/matmul.cpp
modules/gpu/CMakeLists.txt
modules/ocl/include/opencv2/ocl/ocl.hpp
modules/ocl/perf/perf_imgproc.cpp
modules/ocl/src/imgproc.cpp
modules/ocl/src/initialization.cpp
modules/stitching/src/matchers.cpp
modules/video/src/video_init.cpp
modules/videostab/src/global_motion.cpp
Add a call to avcodec_get_context_defaults3, this sets per-codec default values
and in the case of libx264 will stop VideoWriter::open (with fourcc=x264) from
failing due to libx264 complaining about broken ffmpeg default settings.
Set some additional libx264 encoder parameters.
- libavcodec issue
- some decoders alter AVCodecContext width/height values, in a wrong way
- eg. in issue 2815, vp6f decoder changes these values, resulting in distorted / invalid frames
- this patch forces default AVCodecContext values
* removed OpenGLFuncTab, now extensions are loaded internally
* added support of GlBuffer and GlTexture2D to InputArray/OutputArray
* added ELEMENT_ARRAY_BUFFER and PIXEL_PACK_BUFFER targets
* added copyFrom/copyTo method for GlBuffer and GlTexture2D
* removed GlFont
* removed pointCloudShow
* removed OpenGLCleanCallback
* added Access parameter to GlBuffer::mapHost
* added autoRelease parameter to all create methods
* Decouple Video4Linux2 support from Video4Linux as existence of
v4l2 on a system does not imply support for v4l.
* Don't use V4L's struct video_window in V4L2 code.
* Removed __USE_GNU as comment says:
/* support for MJPEG is only available with libjpeg and gcc,
because it's use libjepg and fmemopen()
so replace with test for fmemopen() if found necessary.
The video(4) driver provides a Video4Linux2 compatible API for
various video peripherals. This patch propagates HAVE_VIDEOIO if
the sys/videoio.h include file is found, which is the signature of
video(4).
