13 Commits

Author SHA1 Message Date
sakal
79ede033f6 Refactor VideoCapturerAndroid tests in WebRTC.
Camera1 tests are now separated from general CameraVideoCapturer tests.
Main motivation behind these changes is that Camera2 implementation can
be tested using the same tests.

CL also reduces code duplication on tests using textures.

BUG=webrtc:5519

Review-Url: https://codereview.webrtc.org/2024843002
Cr-Commit-Position: refs/heads/master@{#13130}
2016-06-14 12:33:48 +00:00
magjed
453018a29e CameraEnumerationAndroid: Remove Enumerator class
BUG=webrtc:5519

Review-Url: https://codereview.webrtc.org/2015143004
Cr-Commit-Position: refs/heads/master@{#12999}
2016-06-01 21:39:43 +00:00
magjed
ce17e01bf6 Reland of Android: Change camera fps range selection (patchset #1 id:1 of https://codereview.webrtc.org/2021233002/ )
Reason for revert:
Fixed gyp bug.

Original issue's description:
> Revert of Android: Change camera fps range selection (patchset #4 id:100001 of https://codereview.webrtc.org/2013413002/ )
>
> Reason for revert:
> Breaks chromium fyi:
> https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/13565
> on step 'generate_build_files':
> gyp: /b/build/slave/Mac_Builder/build/src/third_party/build/android/test_runner.gypi not found
>
> Original issue's description:
> > Android: Change camera fps range selection
> >
> > This CL changes the logic in
> > CameraEnumerationAndroid.getClosestSupportedFramerateRange() to prefer
> > fps ranges with a low lower bound so the camera can adjust for
> > brightness conditions.
> >
> > To test the functionality of the fps range selection, JUnit tests are
> > added. This required a new target in api_tests.gyp. JUnit tests are
> > preferable over instrumentation tests
> > (libjingle_peerconnection_android_unittest) because they are faster and
> > simpler.
> >
> > R=kjellander@webrtc.org, sakal@webrtc.org
> >
> > Committed: https://crrev.com/b4ddb5c3d3706b1c02437f6a538576f3552ab908
> > Cr-Commit-Position: refs/heads/master@{#12964}
>
> TBR=sakal@webrtc.org,kjellander@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Committed: https://crrev.com/b3f208d0ba45f140272e3e705b5cdadc3c76514b
> Cr-Commit-Position: refs/heads/master@{#12966}

TBR=sakal@webrtc.org,kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review-Url: https://codereview.webrtc.org/2028583002
Cr-Commit-Position: refs/heads/master@{#12980}
2016-06-01 07:44:07 +00:00
magjed
b3f208d0ba Revert of Android: Change camera fps range selection (patchset #4 id:100001 of https://codereview.webrtc.org/2013413002/ )
Reason for revert:
Breaks chromium fyi:
https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/13565
on step 'generate_build_files':
gyp: /b/build/slave/Mac_Builder/build/src/third_party/build/android/test_runner.gypi not found

Original issue's description:
> Android: Change camera fps range selection
>
> This CL changes the logic in
> CameraEnumerationAndroid.getClosestSupportedFramerateRange() to prefer
> fps ranges with a low lower bound so the camera can adjust for
> brightness conditions.
>
> To test the functionality of the fps range selection, JUnit tests are
> added. This required a new target in api_tests.gyp. JUnit tests are
> preferable over instrumentation tests
> (libjingle_peerconnection_android_unittest) because they are faster and
> simpler.
>
> R=kjellander@webrtc.org, sakal@webrtc.org
>
> Committed: https://crrev.com/b4ddb5c3d3706b1c02437f6a538576f3552ab908
> Cr-Commit-Position: refs/heads/master@{#12964}

TBR=sakal@webrtc.org,kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review-Url: https://codereview.webrtc.org/2021233002
Cr-Commit-Position: refs/heads/master@{#12966}
2016-05-31 08:44:34 +00:00
Magnus Jedvert
b4ddb5c3d3 Android: Change camera fps range selection
This CL changes the logic in
CameraEnumerationAndroid.getClosestSupportedFramerateRange() to prefer
fps ranges with a low lower bound so the camera can adjust for
brightness conditions.

To test the functionality of the fps range selection, JUnit tests are
added. This required a new target in api_tests.gyp. JUnit tests are
preferable over instrumentation tests
(libjingle_peerconnection_android_unittest) because they are faster and
simpler.

R=kjellander@webrtc.org, sakal@webrtc.org

Review URL: https://codereview.webrtc.org/2013413002 .

Cr-Commit-Position: refs/heads/master@{#12964}
2016-05-31 08:19:02 +00:00
magjed
e38a93663a Reland of Android: Add FramerateRange class (patchset #1 id:1 of https://codereview.webrtc.org/2024573002/ )
Reason for revert:
Updated signature to work with other JNI versions. We would need to compile it differently in order to catch failures like this in WebRTC in the future.

Original issue's description:
> Revert of Android: Add FramerateRange class (patchset #2 id:60001 of https://codereview.webrtc.org/2010763003/ )
>
> Reason for revert:
> Breaks downstream Android tests:
> java.lang.NoSuchFieldError: no field with name='framerate' signature='org/webrtc/CameraEnumerationAndroid$CaptureFormat$FramerateRange' in class Lorg/webrtc/CameraEnumerationAndroid$CaptureFormat;
>
> We should have a similar test in WebRTC so we can catch such errors pre-commit.
>
> Original issue's description:
> > Android: Add FramerateRange class
> >
> > The Camera1 and Camera2 API use different framerate range types. Camera1
> > uses int[2] and Camera2 uses Range<Integer>. Range<Integer> is
> > unfortunately only available on Lollipop and later, so this CL adds a
> > similar FramerateRange class in CaptureFormat.
> >
> > The purpose with this CL is to have a common framerate range type that can
> > be reused from both Camera1 and Camera2 in helper functions such as
> > CameraEnumerationAndroid.getClosestSupportedFramerateRange().
> >
> > BUG=webrtc:5519
> > R=sakal@webrtc.org
> >
> > Committed: https://crrev.com/94cb67d6df1a78e7fa25e469f719c1a8809dc583
> > Cr-Commit-Position: refs/heads/master@{#12942}
>
> TBR=sakal@webrtc.org,magjed@webrtc.org
> NOTRY=True
> BUG=webrtc:5519
>
> Committed: https://crrev.com/bd5621f065fd25e0a77307f10dc9ddaf76e7945f
> Cr-Commit-Position: refs/heads/master@{#12956}

TBR=sakal@webrtc.org,kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5519

Review-Url: https://codereview.webrtc.org/2019333002
Cr-Commit-Position: refs/heads/master@{#12957}
2016-05-30 11:00:27 +00:00
kjellander
bd5621f065 Revert of Android: Add FramerateRange class (patchset #2 id:60001 of https://codereview.webrtc.org/2010763003/ )
Reason for revert:
Breaks downstream Android tests:
java.lang.NoSuchFieldError: no field with name='framerate' signature='org/webrtc/CameraEnumerationAndroid$CaptureFormat$FramerateRange' in class Lorg/webrtc/CameraEnumerationAndroid$CaptureFormat;

We should have a similar test in WebRTC so we can catch such errors pre-commit.

Original issue's description:
> Android: Add FramerateRange class
>
> The Camera1 and Camera2 API use different framerate range types. Camera1
> uses int[2] and Camera2 uses Range<Integer>. Range<Integer> is
> unfortunately only available on Lollipop and later, so this CL adds a
> similar FramerateRange class in CaptureFormat.
>
> The purpose with this CL is to have a common framerate range type that can
> be reused from both Camera1 and Camera2 in helper functions such as
> CameraEnumerationAndroid.getClosestSupportedFramerateRange().
>
> BUG=webrtc:5519
> R=sakal@webrtc.org
>
> Committed: https://crrev.com/94cb67d6df1a78e7fa25e469f719c1a8809dc583
> Cr-Commit-Position: refs/heads/master@{#12942}

TBR=sakal@webrtc.org,magjed@webrtc.org
NOTRY=True
BUG=webrtc:5519

Review-Url: https://codereview.webrtc.org/2024573002
Cr-Commit-Position: refs/heads/master@{#12956}
2016-05-30 06:06:31 +00:00
Magnus Jedvert
94cb67d6df Android: Add FramerateRange class
The Camera1 and Camera2 API use different framerate range types. Camera1
uses int[2] and Camera2 uses Range<Integer>. Range<Integer> is
unfortunately only available on Lollipop and later, so this CL adds a
similar FramerateRange class in CaptureFormat.

The purpose with this CL is to have a common framerate range type that can
be reused from both Camera1 and Camera2 in helper functions such as
CameraEnumerationAndroid.getClosestSupportedFramerateRange().

BUG=webrtc:5519
R=sakal@webrtc.org

Review URL: https://codereview.webrtc.org/2010763003 .

Cr-Commit-Position: refs/heads/master@{#12942}
2016-05-27 08:36:01 +00:00
Alex Glaznev
56d4d059ac Detect and report camera close timeout.
BUG=b/27677113
R=magjed@webrtc.org

Review URL: https://codereview.webrtc.org/1801293004 .

Cr-Commit-Position: refs/heads/master@{#12043}
2016-03-17 22:15:01 +00:00
Magnus Jedvert
5199c74d25 AndroidVideoCapturer getSupportedFormats(): Change interface from JSON string to List/vector
This CL simplifies the VideoCapturer interface from 'String getSupportedFormatsAsJson() throws JSONException' to 'List<CaptureFormat> getSupportedFormats()'. The intermediate conversion to/from a JSON string is removed, and AndroidVideoCapturerJni converts the Java list to a C++ vector directly instead.

BUG=webrtc:5519
R=perkj@webrtc.org

Review URL: https://codereview.webrtc.org/1702603002 .

Cr-Commit-Position: refs/heads/master@{#11669}
2016-02-18 12:10:02 +00:00
Magnus Jedvert
5e7834e151 Android: Make VideoCapturer an interface for all VideoCapturers to implement
This CL factors out the interface that AndroidVideoCapturerJni is using to communicate with the Java counterpart. This interface is moved into VideoCapturer. The interface is not touched in this CL, and a follow-up CL is planned to simplify and improve it.

Another change is that the native part of VideoCapturer is created in PeerConnectionFactory.createVideoSource() instead of doing it immediately in the ctor.

BUG=webrtc:5519
R=perkj@webrtc.org

Review URL: https://codereview.webrtc.org/1696553003 .

Cr-Commit-Position: refs/heads/master@{#11606}
2016-02-12 16:05:36 +00:00
kjellander
b24317bfda Fix license headers in webrtc/api.
In addition to the code moved from talk/app/webrtc
there were some files in webrtc/api/objctests that still
had the libjingle license header.

BUG=webrtc:5418
TBR=tkchin@webrtc.org
NOTRY=True

Review URL: https://codereview.webrtc.org/1680293005

Cr-Commit-Position: refs/heads/master@{#11552}
2016-02-10 15:54:53 +00:00
Henrik Kjellander
15583c19d7 Move talk/app/webrtc to webrtc/api
The previously disabled warnings that were inherited from
talk/build/common.gypi are now replaced by target-specific disabling
of only the failing warnings. Additional disabling was needed since the stricter
compilation warnings that applies to code in webrtc/.

License headers will be updated in a follow-up CL.

Other modifications:
* Updated the header guards.
* Sorted the includes using chromium/src/tools/sort-headers.py
  except for these files:
  talk/app/webrtc/peerconnectionendtoend_unittest.cc
  talk/app/webrtc/java/jni/androidmediadecoder_jni.cc
  talk/app/webrtc/java/jni/androidmediaencoder_jni.cc
  webrtc/media/devices/win32devicemanager.cc

The HAVE_SCTP define was added for the peerconnection_unittests target
in api_tests.gyp.

I also checked that none of
SRTP_RELATIVE_PATH
HAVE_SRTP
HAVE_WEBRTC_VIDEO
HAVE_WEBRTC_VOICE
were used by the talk/app/webrtc code.

For Chromium, the following changes will need to be applied to the roll CL that updates the
DEPS for WebRTC and libjingle:
https://codereview.chromium.org/1615433002

BUG=webrtc:5418
NOPRESUBMIT=True
R=deadbeef@webrtc.org, pthatcher@webrtc.org, tommi@webrtc.org

Review URL: https://codereview.webrtc.org/1610243002 .

Cr-Commit-Position: refs/heads/master@{#11545}
2016-02-10 09:53:26 +00:00