During call setup Opus should always be signaled as a 48000 Hz stereo codec, not depending on what we plan to send, or how we plan to decode received packets.
The previous implementation had different payload types for mono and stereo, which breaks the proposed standard.
While working on this CL I ran in to the problem reported earlier, that we could get a crash related to deleting decoder memory. This should now be solved in Patch Set 3.
BUG=issue1013, issue1112
Review URL: https://webrtc-codereview.appspot.com/933022
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3177 4adac7df-926f-26a2-2b94-8c16560cd09d
These changes makes it possible to run this tool with some gtest additions in an automated manner on the buildbots.
This test was previously known as video_coding_test, which is an
integration test that is mostly used as a development tool.
Parts of this test should be extracted and kept as a separate
development tool, but that's something for a future CL.
I also refactored the old command line parsing to use gflags instead.
Previous code from the following tests were merged into
video_coding_integrationtests and video_coding_unittests:
* video_codecs_test_framework_integrationtests
* video_codecs_test_framework_unittests
So these targets are now gone.
BUG=none
TEST=trybots passing + Executing video_coding_integrationtests on Linux, Mac and Windows since it's not currently added to the trybots. I ran with a couple of different combinations of settings.
Review URL: https://webrtc-codereview.appspot.com/933026
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3176 4adac7df-926f-26a2-2b94-8c16560cd09d
By letting fileutils.h know the path to the executable, the tests will be able to find the project root dir and resource file paths even when the test is executed outside the checkout dir.
See http://review.webrtc.org/858014/ for more background.
Today, these tests are failing in the FYI waterfall since they are run "Chromium style" (i.e. from one level above the checkout dir). Since we're moving in that direction this needs to be fixed. It has been fixed for all other tests already.
TEST=Local test execution of vie_auto_test and voe_auto_test with CWD one level above trunk/
Review URL: https://webrtc-codereview.appspot.com/974004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3173 4adac7df-926f-26a2-2b94-8c16560cd09d
The directx_sdk_path GYP variable got the value $(DXSDK_DIR) on non-windows platforms which is normally an uninitialized environment variable, causing an error during GYP generation.
Putting this include within a condition for Windows resolves this.
This was only triggered when GYP_GENERATORS=ninja and not for the default on Linux (make), so the bots haven't noticed this.
BUG=none
TEST=All default trybots passing. Successfully generating projects on Linux and Mac for make and ninja (plus XCode on Mac). Successful compile on Windows without DirectX SDK installed (but with files located in third_party/directxsdk/files).
Review URL: https://webrtc-codereview.appspot.com/936031
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3156 4adac7df-926f-26a2-2b94-8c16560cd09d
The central problem is that we cannot sync the frames in the input video with the output video, which makes PSNR/SSIM go crazy. The test only appeared to succeed earlier due to a bug in the test. We can consider this a failed experiment, but we did learn a lot from it :)
BUG=550
Review URL: https://webrtc-codereview.appspot.com/969006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3155 4adac7df-926f-26a2-2b94-8c16560cd09d
This makes it possible to keep a copy of the Direct X SDK in third_party/directxsdk/files and get it automatically used instead of having to install it manually on the system.
BUG=none
TEST=Compilation with SDK files in third_party/directxsdk/files and uninstalled Direct X SDK on Windows.
Review URL: https://webrtc-codereview.appspot.com/937028
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3153 4adac7df-926f-26a2-2b94-8c16560cd09d
BUG=1120
TEST=trybot, local test on xoom and nexus
Message:
It turned out the last CL can only build neon code that
caused problem on Xoom.
Description:
In order to support audo-cpu-detection, I split files into two gypi files, one
contains non-neon code, antoher one ONLY contains neon specific code, so I can
apply different flags to them. Also created two build targets for each of them
We build for linux as before.
Tested on xoom and nexus S.
Review URL: https://webrtc-codereview.appspot.com/930024
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3141 4adac7df-926f-26a2-2b94-8c16560cd09d
*****
Restructure the video_capture code a bit to make room for a Media Foundation class implementation.
This change includes the following:
* Skeleton classes for a couple of base MediaFoundation classes (no code yet). See *_mf.*.
* Renaming the DirectShow based implementation from "_windows" to "_ds".
* Move the VideoCaptureImpl::CreateDeviceInfo() method into video_capture_factory_windows.cc
The reason for this is that that's where the other VideoCaptureImpl factory function is
and the factory function won't be implementation specific.
* Removed use of <initguid.h> from a header file to avoid defining the same guids in multiple object files.
(more info here: http://msdn.microsoft.com/en-us/library/windows/desktop/dd375463(v=vs.85).aspx)
* Moved a couple of global variables from the capture_delay_values_windows.h header and into
device_info_ds.cc since that's the only file that uses those variables.
* Delete capture_delay_values_windows.h.
* Added a factory function: DeviceInfoDS::Create() that'll create the DirectShow specific implementation.
TEST=This is mostly moving code around. The code that is added, is currently "dead". No manual testing needed.
BUG=chromium:140545
Review URL: https://webrtc-codereview.appspot.com/967008TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/934017TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/934018
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3137 4adac7df-926f-26a2-2b94-8c16560cd09d
[ RUN ] ViEStandardIntegrationTest.RunsBaseTestWithoutErrors
2012-11-20 13:06:59.625 vie_auto_test[4001:f07] An uncaught exception was raised
2012-11-20 13:06:59.625 vie_auto_test[4001:f07] Error (1000) creating CGSWindow on line 259
2012-11-20 13:06:59.670 vie_auto_test[4001:f07] (
0 CoreFoundation 0x9a4e912b __raiseError + 219
1 libobjc.A.dylib 0x95ee252e objc_exception_throw + 230
2 CoreFoundation 0x9a448bbb +[NSException raise:format:] + 139
3 AppKit 0x996b4757 _NSCreateWindowWithOpaqueShape2 + 302
4 AppKit 0x996b2f40 -[NSWindow _commonAwake] + 1823
5 AppKit 0x9966fa77 -[NSWindow _commonInitFrame:styleMask:backing:defer:] + 1652
6 AppKit 0x9966eb3f -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1063
7 AppKit 0x9966e704 -[NSWindow initWithContentRect:styleMask:backing:defer:] + 70
8 vie_auto_test 0x0015c232 -[TestCocoaUi createWindows:] + 338
9 libobjc.A.dylib 0x95eef5d3 -[NSObject performSelector:withObject:] + 70
10 Foundation 0x969050c0 __NSThreadPerformPerform + 395
11 CoreFoundation 0x9a3bf66f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
12 CoreFoundation 0x9a3bf099 __CFRunLoopDoSources0 + 233
13 CoreFoundation 0x9a3e4e46 __CFRunLoopRun + 934
14 CoreFoundation 0x9a3e463a CFRunLoopRunSpecific + 378
15 CoreFoundation 0x9a3e44ab CFRunLoopRunInMode + 123
16 Foundation 0x9690d946 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 278
17 vie_auto_test 0x002e490a main + 522
18 vie_auto_test 0x000b1835 start + 53
*****
Restructure the video_capture code a bit to make room for a Media Foundation class implementation.
This change includes the following:
* Skeleton classes for a couple of base MediaFoundation classes (no code yet). See *_mf.*.
* Renaming the DirectShow based implementation from "_windows" to "_ds".
* Move the VideoCaptureImpl::CreateDeviceInfo() method into video_capture_factory_windows.cc
The reason for this is that that's where the other VideoCaptureImpl factory function is
and the factory function won't be implementation specific.
* Removed use of <initguid.h> from a header file to avoid defining the same guids in multiple object files.
(more info here: http://msdn.microsoft.com/en-us/library/windows/desktop/dd375463(v=vs.85).aspx)
* Moved a couple of global variables from the capture_delay_values_windows.h header and into
device_info_ds.cc since that's the only file that uses those variables.
* Delete capture_delay_values_windows.h.
* Added a factory function: DeviceInfoDS::Create() that'll create the DirectShow specific implementation.
TEST=This is mostly moving code around. The code that is added, is currently "dead". No manual testing needed.
BUG=chromium:140545
Review URL: https://webrtc-codereview.appspot.com/967008TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/934017
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3136 4adac7df-926f-26a2-2b94-8c16560cd09d
This change includes the following:
* Skeleton classes for a couple of base MediaFoundation classes (no code yet). See *_mf.*.
* Renaming the DirectShow based implementation from "_windows" to "_ds".
* Move the VideoCaptureImpl::CreateDeviceInfo() method into video_capture_factory_windows.cc
The reason for this is that that's where the other VideoCaptureImpl factory function is
and the factory function won't be implementation specific.
* Removed use of <initguid.h> from a header file to avoid defining the same guids in multiple object files.
(more info here: http://msdn.microsoft.com/en-us/library/windows/desktop/dd375463(v=vs.85).aspx)
* Moved a couple of global variables from the capture_delay_values_windows.h header and into
device_info_ds.cc since that's the only file that uses those variables.
* Delete capture_delay_values_windows.h.
* Added a factory function: DeviceInfoDS::Create() that'll create the DirectShow specific implementation.
TEST=This is mostly moving code around. The code that is added, is currently "dead". No manual testing needed.
BUG=chromium:140545
Review URL: https://webrtc-codereview.appspot.com/967008
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3135 4adac7df-926f-26a2-2b94-8c16560cd09d
This is a copy of http://review.webrtc.org/864014/
This adds a FuncDurationEst to each codec instance which estimates
the duration of a packet given the packet contents and the duration
of the previous packet. By default, this simply returns the
duration of the previous packet (which is what is currently assumed
to be the duration of all future packets). This patch also provides
an initial implementation of this function for G.711 which returns
the actual number of samples in the packet.
BUG=issue1015
Review URL: https://webrtc-codereview.appspot.com/935016
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3129 4adac7df-926f-26a2-2b94-8c16560cd09d
