series are supported. Testing this with both cams for Windows and Linux
exhaustively.
Optimizing memory footprint by removing unused calls.
Adapted with the input of Shai
Added small example that illustrates how it should work.
superres module fails to compile with the following error messages:
[100%] Building CXX object modules/superres/CMakeFiles/opencv_superres.dir/src/super_resolution.cpp.o
/opencv-2.4.10/modules/superres/src/frame_source.cpp: In function 'cv::Ptr<cv::superres::FrameSource> cv::superres::createFrameSource_Video_GPU(const string&)':
/opencv-2.4.10/modules/superres/src/frame_source.cpp:263:16: error: expected type-specifier before 'VideoFrameSource'
/opencv-2.4.10/modules/superres/src/frame_source.cpp:263:16: error: could not convert '(int*)operator new(4ul)' from 'int*' to 'cv::Ptr<cv::superres::FrameSource>'
/opencv-2.4.10/modules/superres/src/frame_source.cpp:263:16: error: expected ';' before 'VideoFrameSource'
/opencv-2.4.10/modules/superres/src/frame_source.cpp:263:41: error: 'VideoFrameSource' was not declared in this scope
/opencv-2.4.10/modules/superres/src/frame_source.cpp:264:1: error: control reaches end of non-void function [-Werror=return-type]
cc1plus: some warnings being treated as errors
make[3]: *** [modules/superres/CMakeFiles/opencv_superres.dir/src/frame_source.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs....
This is caused because the return value of the createFrameSource_Video_GPU function should be a VideoFrameSource_GPU object.
ocl: Change static variable order in cl_context.cpp to avoid crashes during destruction
ContextImpl::currentContext contains a reference to one of the
DeviceInfoImpl objects from:
static std::vector<DeviceInfoImpl> global_devices;
ContextImpl::currentContext is destroyed in the destructor
for the statically defined object __module, and relies on its
DeviceInfoImpl reference to query some hardware features while
being destroyed.
This means that we need to ensure that the global_devices vector is
destroyed affter __module, otherwise ContextImpl::currentContext's
DeviceInfoImpl reference will no longer be valid when __module is
destroyed.
Since these variables are all confined to a single compilation unit,
they will be destruct from bottom to top, so we need to make sure
that __module is the bottom definition so it can be destroyed first.
iOS: fix crash from overrelease in UIImageToMat
viz: fixed memory leak, issue 3961
fix installation layout for debian packages:
Install symlinks to shared libraries as a part of development package,
not runtime package.
It is default behavior for debian packages.
Fix test name.
TIFF loader: Allocate large enough buffer when (bpp * ncn) > 8.
TIFF loader: Pass buffer size to read functions.
replace not ascii and not cyrillic symbols with '?';
add test for putText;
fix warning;
minor fixes;
ContextImpl::currentContext contains a reference to one of the
DeviceInfoImpl objects from:
static std::vector<DeviceInfoImpl> global_devices;
ContextImpl::currentContext is destroyed in the destructor
for the statically defined object __module, and relies on its
DeviceInfoImpl reference to query some hardware features while
being destroyed.
This means that we need to ensure that the global_devices vector is
destroyed affter __module, otherwise ContextImpl::currentContext's
DeviceInfoImpl reference will no longer be valid when __module is
destroyed.
Since these variables are all confined to a single compilation unit,
they will be destruct from bottom to top, so we need to make sure
that __module is the bottom definition so it can be destroyed first.
This bug was triggered by Buildroot autobuilders [1,2], causing this
kind of failures [3,4]:
[ 14%] Building CXX object modules/core/CMakeFiles/opencv_core.dir/src/system.cpp.o
/home/test/autobuild/instance-0/output/build/opencv-2.4.10/modules/core/src/system.cpp: In function '(static initializers for /home/test/autobuild/instance-0/output/build/opencv-2.4.10/modules/core/src/system.cpp)':
/home/test/autobuild/instance-0/output/build/opencv-2.4.10/modules/core/src/system.cpp:280:10: error: inconsistent operand constraints in an 'asm'
make[3]: *** [modules/core/CMakeFiles/opencv_core.dir/src/system.cpp.o] Error 1
[1] http://buildroot.org/
[2] http://autobuild.buildroot.org/
[3] http://autobuild.buildroot.org/?reason=opencv-2.4.10
[4] http://autobuild.buildroot.org/results/483/4838285b25d6293a5cf0bb9eadd5040a7c75d766/build-end.log
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Fixed the non-working code example for NAryMatIterator.
The documentation of NAryMatIterator in file:
modules/core/include/opencv2/core/core.hpp has a working example which
was used for these edits.
Currently, FFMPEG source files are included in highgui project file regardless of CMake WITH_FFMPEG option.
After applying this PR FFMPEG files are included only if WITH_FFMPEG option is enabled.
In C99 'inline' is not a hint to the compiler to inline the function,
it is an attribute that affects the linkage of the function. 'inline'
functions are required to have a definition in a different compiliation
unit, so compilers are free to delete 'inline' functions if they want to.
This issue can be seen in Clang when compiling at -O0. Clang
will sometimes delete 'inline' functions which creates an invalid
program.
Issue 3746: http://code.opencv.org/issues/3746
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
In CUDA 6.0 there was a bug in NPP LUT implementation (invalid results when
src == 255). In CUDA 6.5 the bug was fixed.
Replaced NPP LUT call with own implementation (ported from master branch)
to be independant from CUDA Toolkit version.
A self-assignment leads to a call of release() with refcount being 2. In the release() method, refcount is decremented and then successfully checked for being 1. As a consequence, the underlying data is released. To prevent this, we test for a self-assignment
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.
