- Substituted HAVE_WINRT with WINRT
- Fixed compilation issues in ocl.cpp and parallel.cpp
- Fixed compiler issue for WP8: "C2678: binary '+' : no operator found which takes a left-hand - Fixed gitignore
- Added #ifdef HAVE_OPENCL to remove compiler warnings in ocl.cpp
- Used NO_GETENV similar to '3rdparty\libjpeg\jmemmgr.c;
- Added ole32.lib for core module (for WindowsStore 8.0 builds)
- Made OpenCV_ARCH aware of ARM
Signed-off-by: Maxim Kostin <v-maxkos@microsoft.com>
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
- 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
* #1538 from StevenPuttemans:bugfix_3283
* #1545 from alalek:ocl_test_fix_rng
* #1551 from alalek:cmake_install_win
* #1570 from ilya-lavrenov:ipp_warn_fix
* #1573 from alalek:perf_simple_strategy
* #1574 from alalek:svm_workaround
* #1576 from alalek:ocl_fix_cl_double
* #1577 from ilya-lavrenov:ocl_setto_opencl12
* #1578 from asmorkalov:android_fd_cp_fix
* #1579 from ilya-lavrenov:ocl_norm
* #1582 from sperrholz:ocl-arithm-additions
* #1586 from ilya-lavrenov:ocl_setto_win_fix
* #1589 from ilya-lavrenov:pr1582_fix
* #1591 from alalek:ocl_remove_cl_hpp_h
* #1592 from alalek:ocl_program_cache_update
* #1593 from ilya-lavrenov:ocl_war_on_double
* #1594 from ilya-lavrenov:ocl_perf
* #1595 from alalek:cl_code_cleanup
* #1596 from alalek:test_fix_run_py
* #1597 from alalek:ocl_fix_cleanup
* #1598 from alalek:ocl_fix_build_mac
* #1599 from ilya-lavrenov:ocl_mac_kernel_warnings
* #1601 from ilya-lavrenov:ocl_fix_tvl1_and_sparse
* #1602 from alalek:ocl_test_dump_info
* #1603 from ilya-lavrenov:ocl_disable_svm_noblas
* #1605 from alalek:ocl_fixes
* #1606 from ilya-lavrenov:ocl_imgproc
* #1607 from ilya-lavrenov:ocl_fft_cleanup
* #1608 from alalek:fix_warn_upd_haar
* #1609 from ilya-lavrenov:ocl_some_optimization
* #1610 from alalek:ocl_fix_perf_kalman
* #1612 from alalek:ocl_fix_string_info
* #1614 from ilya-lavrenov:ocl_svm_misprint
* #1616 from ilya-lavrenov:ocl_cvtColor
* #1617 from ilya-lavrenov:ocl_info
* #1622 from a0byte:2.4
* #1625 from ilya-lavrenov:to_string
Conflicts:
cmake/OpenCVConfig.cmake
cmake/OpenCVDetectPython.cmake
cmake/OpenCVGenConfig.cmake
modules/core/CMakeLists.txt
modules/nonfree/src/surf.ocl.cpp
modules/ocl/include/opencv2/ocl/ocl.hpp
modules/ocl/include/opencv2/ocl/private/util.hpp
modules/ocl/perf/main.cpp
modules/ocl/src/arithm.cpp
modules/ocl/src/cl_operations.cpp
modules/ocl/src/cl_programcache.cpp
modules/ocl/src/color.cpp
modules/ocl/src/fft.cpp
modules/ocl/src/filtering.cpp
modules/ocl/src/gemm.cpp
modules/ocl/src/haar.cpp
modules/ocl/src/imgproc.cpp
modules/ocl/src/matrix_operations.cpp
modules/ocl/src/pyrlk.cpp
modules/ocl/src/split_merge.cpp
modules/ocl/src/svm.cpp
modules/ocl/test/main.cpp
modules/ocl/test/test_fft.cpp
modules/ocl/test/test_moments.cpp
modules/ocl/test/test_objdetect.cpp
modules/ocl/test/test_optflow.cpp
modules/ocl/test/utility.hpp
modules/python/CMakeLists.txt
modules/ts/include/opencv2/ts.hpp
modules/ts/src/ts_perf.cpp
samples/android/face-detection/jni/DetectionBasedTracker_jni.cpp
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.
Now the HAVE_* macros are set using cvconfig.h. Previously most
of them already were there, but were always undefined. One,
HAVE_COCOA, I had to add.
This also makes the CMake code more consistent; now, WITH_* variables
are always checked in cmake/*, while HAVE_* variables are checked in
modules/highgui/CMakeLists.txt.
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
Merged pull requests:
#890 from caorong:patch-1
#893 from jet47:gpu-arm-fixes
#933 from pengx17:2.4_macfix_cont
#935 from pengx17:2.4_filter2d_fix
#936 from bitwangyaoyao:2.4_perf
#937 from bitwangyaoyao:2.4_fixPyrLK
#938 from pengx17:2.4_surf_sample
#939 from pengx17:2.4_getDevice
#940 from SpecLad:autolock
#941 from apavlenko:signed_char
#946 from bitwangyaoyao:2.4_samples2
#947 from jet47:fix-gpu-arm-build
#948 from jet47:cuda-5.5-support
#952 from SpecLad:jepg
#953 from jet47:fix-bug-3069
#955 from SpecLad:symlink
#957 from pengx17:2.4_fix_corner_detector
#959 from SpecLad:qt4-build
#960 from SpecLad:extra-modules
Conflicts:
modules/core/include/opencv2/core/core.hpp
modules/gpu/CMakeLists.txt
modules/gpu/include/opencv2/gpu/device/vec_math.hpp
modules/gpu/perf/perf_video.cpp
modules/gpuimgproc/src/cuda/hough.cu
modules/ocl/include/opencv2/ocl/ocl.hpp
modules/ocl/src/pyrlk.cpp
samples/gpu/driver_api_multi.cpp
samples/gpu/driver_api_stereo_multi.cpp
samples/ocl/surf_matcher.cpp
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).
Window-related functions is guarded from calls from application code.
Old implementations with "no-gui" exception are stell compiled and linked to OpenCV library for binary compatibility.
